Search the Community
Showing results for tags 'files'.
Found 4 results
The Lower Planes has had the following foibles and changes recently. Complete failure of HD on which it was stored Therefore a complete rebuild, which after some foibles of its own is now fully functional and improved from before Local message areas for Apple II, General, and FSX net for those interested. Super Stocked and growing file areas. I'd give my left testicle to figure out why x/y/z modem refuse to work, so FTP is really the only transfer option Files are packed in .shk format as per the halcyon days, to load into your existing system more readily Message base has had a complete reset, but its starting to bop along again. Online games have all been reset too. The Lower Planes firmly reccommends ProTerm, Megaterm, and Agate for enhanced viewing pleasure. You can have sexy ansi (slower), basic ansi (highlighting in colour, faster) or the standby standard of ASCII Would still like to investigate a message network between GBBS pro systems. Not sure what can be done with Warp6. A tlp.zapto.org www/telnet/ssh/ftp initial login is through a linux system which requires a login:password of bbs:bbs.
I'm using my HDR ramdisk a lot while developing my TiVi editor. It's a real time saver. It's especially helpful when dealing with large files (which is kinda my primary purpose why I started working on TiVi). Today I read the updated documenation the InsaneMultitasker provided as draft. In there I learned that with ROS it's possible to use data buffers that reside in CPU RAM insead of VDP RAM. That is something I really want to try, because even with a RAMDISK reading a large file (think >100 kilobytes) takes some time. Now my challenge is; How can I easily detect from assembly language if I'm dealing with a "high-speed" disk device compared to a "slow" disk device ("floppy"). With a high-speed device I mean: CF7+, Nanopeb TIPI HDR ... I see differents possible paths here: CRC checksum on DSR space (but won't work with RAMBOS? Self modifiying code, configuration stored here too?) Check on some specific device feature? Actually I think that the CRC checksum logic would work quite well (I already did a test program on that about a year ago), but I'm not sure about HDR. Thinking about it would be cool if there is some unified way to detect device capabilities accross devices. For example a standard where there's a device "capabilities" file that is automatically created when the device is formatted. That file could then be processed from TI-Basic, assembly language or any other language supporting file I/O. Any ideas?
When running some xdt99 cross-checks in Classic99 I noticed that the end-of-file byte marker for DIS/VAR files generated as FIAD files seems to be off by one. BASIC program: 10 OPEN #1:"DSK2.ONELINE",DISPLAY ,OUTPUT,VARIABLE 32 20 PRINT #1:"123456789" 30 CLOSE #1 Resulting FIAD file: 00000000 4f 4e 45 4c 49 4e 45 20 20 20 00 00 80 07 00 01 |ONELINE ......| 00000010 0b 20 01 00 00 00 00 00 00 00 00 00 00 00 00 00 |. ..............| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| FDR on MESS disk image: 00: 4F 4E 45 4C 49 4E 45 20 20 20 00 00 80 07 00 01 ONEL INE .. .... 10: 0A 20 01 00 A9 79 1E C2 A9 79 1E C2 22 00 00 00 . .. .y.. .y.. "... 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .... .... .... .... The EOF byte is "0B" in the FIAD file but "0A" in the disk image. Is this a "feature" of FIAD files that the EOF marker is off by one? I currently cannot double-check what v9t9 does (but Win994a agrees with MESS). I also noticed that Classic99 has issues with EOF in Extended Basic. More specifically, it reads past EOF when using MESS disk images. ... 1000 IF EOF(1)THEN RETURN 1010 INPUT #1:L$ ... -> I/O ERROR 25 IN 1010 Could this be related?
Okay folks...here we go. These are palette files from an actual NTSC color palette generator. The first set has a "standard", but some people may prefer or have televisions that either emphasized green or red more (aka Tint/Hue Control). Also, if you have adjusted the color pot in the 7800 unit itself, it can also account for these slight variations. The following variety of files accounts for that and hopefully more for you: NEUT.pal - Neutral Standard NEUT_MINUS_05.pal - NEUT.pal with minus 05 degree shift (Red Lean) NEUT_MINUS_10.pal - NEUT.pal with minus 10 degree shift (More Red) NEUT_MINUS_15.pal - NEUT.pal with minus 15 degree shift (Most Red) NEUT_PLUS_05.pal - NEUT.pal with plus 05 degree shift (Green Lean) NEUT_PLUS_10.pal - NEUT.pal with plus 10 degree shift (More Green) NEUT_PLUS_15.pal - NEUT.pal with plus 15 degree shift (Most Green) The next set contains two slight adjustments to contrast and saturation providing a more pleasing looking (and IMHO, more TV realistic) colors: NEUTADJ.pal - NEUT.pal with 33.3% less contrast and 50% less saturation NEUTADJ_MINUS_05.pal - NEUTADJ.pal with minus 05 degree shift (Red Lean) NEUTADJ_MINUS_10.pal - NEUTADJ.pal with minus 10 degree shift (More Red) NEUTADJ_MINUS_15.pal - NEUTADJ.pal with minus 15 degree shift (Most Red) NEUTADJ_PLUS_05.pal - NEUTADJ.pal with plus 05 degree shift (Green Lean) NEUTADJ_PLUS_10.pal - NEUTADJ.pal with plus 10 degree shift (More Green) NEUTADJ_PLUS_15.pal - NEUTADJ.pal with plus 15 degree shift (Most Green) No matter what palette you choose you will immediately see 'base' appropriate colors in situations like the enemy birds in 'Joust', the forest in 'Bentley Bear - Crystal Quest', and the latest 'Tank Command - Midnight Run' & 'Donkey Kong - Pokey Sound' (Arcade colors) hack, as well as appropriate colors in other standard/original titles - Xenophobe, Dig Dug, Ms. Pac-Man, Commando, etc. Ideally it would be great to see ProSystem, MESS, and all other Atari 7800 emulators incorporate something like Blargg effects or their own internal NTSC color generator. For now though, I hope this helps and benefits the community, Trebor PaletteRC1.zip