Jump to content

CharlieChaplin

Members
  • Content Count

    3,223
  • Joined

  • Last visited

Community Reputation

1,512 Excellent

About CharlieChaplin

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Gender
    Male

Recent Profile Visitors

17,356 profile views
  1. The pics are named RGB9, because they use Gr. 9 (not 11), one picture should use 16 red tones (R), the next 16 green tones (G) and the last one 16 blue tones (B). The problem I see, why the pics look so bad on PAL machines is that Jeff Potter (JP) used a fixed NTSC colour palette for both Apacview and Jview (and several of his other picture converters). If I remember correctly, the A8 has in its NTSC palette two red tones (in 8 or 16 luminances), whereas PAL has 1 brown tone and one red tone at that place (in 8 or 16 luminances). So, if JP used the NTSC red tone in his Apacview or Jview palette that's actually a brown tone on PAL, this would explain why the RGB pictures look so bad on PAL (no red available). Unsure, why the RGB15 pics look so much better in comparison, since they should have the same (palette) problem as the RGB9 pics... In Apacview JP used an external palette (named Apacdat.OBJ on my image, length 33 sectors), in ILBMRead he also used an external palette (named IFFdat.OBJ on my image, same palette, length 33 sectors), but it seems that the palette is internal in JView and Colrview. Would be nice to get these converters with PAL palettes or a program that checks if a PAL or NTSC system is there and then sets the appropriate palette, but I know that will never happen (only in my dreams), so I have to live with it. Attached are some of the Graphic converters I used in the past, including Apacview, Jview, Colrview and several others... And errm, allthough the uploaded A8 RGB pictures look quite pale, the original pictures were not pale at all, quite the opposite, they were very colourful and had rich colours (Nintendo-style). Maybe I can find them again and post some examples... grtools.zip
  2. Well, if it is the old Sectorcopy by Craig Chamberlain, this one will copy 720 sectors (90k), not 720k. It will read the first three sectors and then give an error, since sector 4 is double density... To copy 720k disk images with the A8 use either Copymate XE or Disk Duplication (or one of the up to 16MB programs, set to e.g. 80 tracks, DS, DD or simply 2880 DD sectors, with start sector = 1 and end sector = 2880). Copymate requires 128k RAM to work, press Return, then TAB (or vice-versa) and finally Start to read+write 720k. Disk Duplication works with 48k/64k, use full disk copy and setup for 80 tracks, double-sided and double density. Do something else in the meanwhile, since copying 720k disks on the A8 takes some time... COPY720K.ATR
  3. Think the house picture came on a disk with Technicolour Dream pictures and I converted them into Apac (by sacrificing some lines, since TD has approx. 80x110 resolution, whereas the Apac format I used had only 80x96 resolution)...
  4. Here are some RGB pictures from my collection (most Anime/Manga pics have been converted by me, while I only collected the others). Boot the images with Basic enabled, since the viewer on most of them is written in Basic, first press 1 for Dir. of drive 1 and then A to view all RLE-compressed RGB pictures. Did also some .PCX emulator screenshots of four RGB9 pics. (with PAL settings and OlivierP palette) and when XnView counted the colours of these PCX images it said, they have between 30 and 49 colours (converted them into JPG then for those that cannot view PCX images, but the colour count for these JPEG's is incorrect and way too high compared to the original pictures)... RGB9_screenshots.zip RGB_pics.zip
  5. The correction is very easy: "Later, Potter created another GIF decoder, named JView, which broke an image into the three red, green and blue channels. 16 shades of each, at 80×192 pixels..." Just replace "and later a JPEG decoder was created" with "named JView" - that's all.
  6. Well, simply use 3,5" DD disks and e.g. a sectorcopy program like Copymate XE 3.8, it copies anything from 90k up to 720k (but requires a minimum of 128k RAM). For 90k/130k/180k just press Start to read and write, for 360k and 720k you have to press other keys (TAB, Return) first, before pressing the Start key. Alternatively you can use Disk Duplication 2.0 (DD2) which can also be setup to read/write anything from 90k to 720k (40 tracks, 80 tracks and even 77 tracks) in single, enhanced or double density. DD2 works on a 32k?/48k?/64k system but also supports ramdisk/XRAM when loaded from DOS (e.g. up to 1MB when loaded from MyDOS, it leaves several sectors free/unused, so one can quit to DOS/DUP afterwards). => both sector copy programs are on the image COPY720k.ATR (without DOS) => DD2 is also on the image 16MCOPY1.ATR (with MyDOS and ultraspeed driver) I do have various 3,5" DD disks in 90k and 130k DOS 2.0s and DOS 2.5 format here, so yes, formatting with 90k or 130k under DOS 2.5 (or DOS 2.0) works fine. I am only using the MyDOS format for 360k and 720k disks, all other formats (90k/130k/180k) are still DOS 2.0 (DOS 2.0s and DOS 2.0d) and DOS 2.5. For example "Winter Events" (bootdisk by Anco) is running fine from two 90k disksides on my 3,5" Hyper-XF, the "Cool Emotion" demo (bootdisk) by HARD is running fine from two 130k disksides. => HyperXF1.ATR includes TurboDOS XL/XE, which uses DOS 2.0 and DOS 2.5 format for 90k/130k/180k; the only format that should be avoided here is the 360k format, since TurboDOS uses 4 bytes as sector links there, which no other DOS 2.x does; there is also Hypmode.COM on this image, which can be used to set the Hyper-XF into any of the available (partition) modes, short instructions included afaik... And ermmm, I also have several sector copy programs that can copy/convert any 90k disk (bootdisk or filedisk) into a 130k diskette, so if you want to use as less formats/densities as possible (since the XF and also Hyper-XF cannot detect density change or format change automatically), you could do that and get rid of the 90k format (sectors 721-1040 are simply unused on these 130k disks then)... => HyperXF1.ATR also includes Diskcopy (DSKCOPY.COM) which can be loaded from TurboDOS, it allows copying/converting from 90k to 130k (or from 130k to 90k if sectors 721 to 1040 are unused)... 16MCOPY1.ATR COPY720K.ATR HYPERXF1.ATR
  7. Yep, these are nice examples of standard A8 gfx modes. Okay, would be even nicer to have some more examples from famous A8 demos and games, but thats at least a good start. Think these screenshots and a few more (from demos and games), as well as screenshots for newer/modern A8 gfx modes would belong in this thread... Regarding Roger's pictures, I also wish there would be a separate thread...
  8. Errmm, "Later, Potter created another GIF decoder, and later a JPEG decoder was created, which broke an image into the three red, green and blue channels. 16 shades of each, at 80×192 pixels, would be displayed in an interlaced and flickering fashion. The human eye's persistence of vision would allow the viewer to see 4096 colours (12 bpp) at 80×192, with slight 'rolling' artifacts in solid red, green or blue fields in the image. This was called ColrView mode." there is a small error in that description ("and later a JPEG decoder was created..."). JView was the name of the tool that Jeff Potter created, J stood for the authors name (Jeff) and NOT for JPEG, since that tool only converts GIF-87a pictures into the Colrview modes (Gr.8/9/15 as three separate + uncompressed R,G,B or one compressed *.RGB pic/s). Nowadays almost everyone assumes that JView means JPEG view, but thats not the case, you can only view+convert GIF-87a with it. And errmm, viewing such Gr.9 Colrview pics on a PAL A8, you see nowhere near 4096 colours, not even 256 colours, just 3-4 colours with 16 shades each (very disappointing, luckily the Gr.15 Colrview mode works good on PAL; made several hundred conversions myself back then). Think the only JPEG viewers/decoders we have on the A8 are by Raphael Espino, named A8JDPEG and CPEGview or something like that...
  9. Yeah, the Atari publishers almost always supported the older 48k machines, so games required to work with 48k RAM. There were some A8 games that did require the full 64k RAM, but they were in the minority in the 80s, more than 90% targeted max. 48k RAM. In the end we Atari owners were happy when we got a conversion and enthusiastic if it was a good one... Besides, the problem with the 600XL not loading disks correctly might be because of its OS - XL-OS Rev. 1, most 600XL came with it (and even a few 800XL computers), while the later standard for XL/XE computers was XL-OS Rev. 2. There are several commercial disks that require XL-OS Rev. 2 and will not work correctly or not at all with Rev. 1, so changing the OS may help, in case you still have the 600XL. (In the 90s I visited a friend and we wanted to play a dozen or more of the newest commercial games from Poland on his 64k/1064 upgraded 600XL, alas, almost none of them worked, since he had XL-OS Rev. 1; luckily I brought my 800XL with XL-OS Rev. 2 with me and there all games did work fine.)
  10. Back to topic. Maybe someone can post some nice screens that a) show all available standard A8 gfx. modes (one pic/screen each for Gr. 0 to Gr. 15) and b) several screens with new/modern gfx. modes like HIP, RIP, TIP, CIN, MAX and many others...?!? For the standard modes it would be nice to have some game or demo screens (e.g. "this example shows a Gr. 0 screen:", "this example shows a Gr. 1 screen:", etc.), for the modern gfx maybe one could use some picture or demo screens... ?!?
  11. My personal collection, my personal choice... (Kept the Bomber title screen, removed the other screens; after the title, the game loads.) But don't worry, I don't have an A8 webpage for downloads, so the "shortened" programs do remain in my personal collection only. Back in the 80s this was done more often, to save space and loading time, especially for tape users. And I have been a tape-only user until 1992 or 1993, when I bought my first A8 disk drive... so I am used to having games without any title picture or just one title picture... Much easier, I am no programmer so I did not disassemble anything. Just loaded the XEX into a packer / linker and removed some data segments (and init adresses) and tested the end result again and again, until it worked like I wanted... And when I could not get it working, I asked some Atari friends to do it for me...
  12. If loading large games (e.g. the ones requiring XRAM) from tape, I would pack them first with a good packer, e.g. Superpacker and its Exomizer or Inflate/Deflate option. Depacking works faster than loading the unpacked data from tape, afaik... Some guys from Abbuc are still analyzing and checking the various Turbo 6000 (Chaos, Schleife, ...) hardware and software versions and their variations. But they already built a Turbo 6000 and loaded a tape with 6000 Baud successfully. (Think they are still busy with checking the many hw and sw variations.)
  13. Hehe, that's why I ask sometimes to have no more than one title or loading picture in front of a game. If loading (playing) the game several times it gets boring (annoying) to load several intro/title/loading pictures again and again. Evil as I am, I changed Bomber, Mighty Jill and a few other games (think Bosconian also) in my personal collection to have only one loading or title screen and removed all others (e.g. removed all lesbian screens from final version of Mighty Jill)...
  14. Yep, it's flicker-hell on PAL and hurts your eyes within a few seconds. Not useful within any game or program, not even useful as a "still" picture since it does not stand still (flickers extremely badly). Whoever said Crownland has flicker should look at this picture on PAL for several seconds - now everything, including the real world, has flicker... Besides, this picture as well as most Rasta pictures do not look as good on the real A8 as they do in the screenshots here. Why ? On the A8 it is (they are) fullscreen, so you can see every single pixel, if you are sitting in front of the screen (e.g. only 30-50 cm away). You have to stay away some 2-3 meters from the screen to see and recognize the whole picture. [Set the emulator window to fullscreen to see what I mean...]
  15. Screenshots from Fandal's page here: Crossfire colour vs. b/w Think the colour version = cart version and the b/w version = disk version...
×
×
  • Create New...