Search the Community
Showing results for tags 'Files'.
-
Hi, as some of us maybe already know, Chris Bobbitt from former ASGARD Software is sending around his findings from his very old Asgard Software Archive to us, to get it digitalized and to share it to the community. What a great move !!! Thanks to Chris, again. As I am one of the lucky guys getting some of this stuff here, my very first action was to make DSKs from the floppydisks he sent to me this week. I attach them here as a ZIP, including a small docu and some screentprints from my testings. I also add some pics of the first ship, as an overview for you. Regarding the amount of paper, it will take some time for me to make scans of that, of course. But, if you see anything very interesting here in the pics, just let me know, so I would do an immediate, selected scan for you. More floppydisks are on the way, to be handled quickly to pass through to all 99ers. I think this will be a big event for all of us, diggin´ through all this fine treasures Many many thanks and all tribute to Chris schmitzi
-
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?
-
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.
-
Hey all, Here is a question... so the TI disk system reserves space at the top of VDP memory for file buffers. You can reduce this by from 3 file support to 1 by calling the FILES subprogram, but it still takes up space from about >3B00 onwards. My question is... can you safely wipe out this section, say if you wanted to put the sprite pattern table at >3800 onwards? Obviously it would trash the sprite pattern table if you had to do a file load later on, but if you could restore the data from CPU memory afterwards it seems alright. Obviously it would be stupid to try and do a memory image load INTO this section...
-
Here is something I have worked on the weeking. It's some testfiles for un-crunching BASIC programs. The txt files are the LIST output of those programs, so they are matching exactly the way the BASIC INTERPRETER does the uncrunching of each basic line of the program. (Classic99 was used with LIST "CLIP" to generate those txt files) If you compare that to the available tools (TI99DIR, imagetool,...) you will see that all have some issues in recreating that same syntax. Example: Output from TI99dir of Line 4 of XBCMD1 4 ACCEPTVALIDATE("YN"):R$ Output from TiImageTool of Line 4 of XBCMD1 4 ACCEPT VALIDATE ("YN"):R$ while if you LIST the program in the TI99 you will see: 4 ACCEPT VALIDATE("YN"):R$ XBCMD1 contains examples for XB commands from A-P XBCDM2 contains examples for XB commands from P-Z XBCMD3 contains quote examples XBCMD4 contains all characters within strings from 0 to 255. Here the txt File fails for line 100 because it interprets some control character. The examples for XB commands are mostly taken from the XB Manual and are only extended by me if insufficient. I will create some more testfiles and add them as Unit Tests to Web99, so in case i touch the code, I immediately see if I broke some behavior. Feel free to do the same for your projects or use the files to manually test your tool during development. Btw: The programs can be loaded, but running them makes no sense, their purpose is to find out if your Tool decodes a TiFile into the Basic Source Code the same way the Basic Interpreter does. Please provide feedback if you want to use it, so I can provide you with updates. unittest.dsk XBCMD1.txt XBCMD2.txt XBCMD3.txt XBCMD4.txt
-
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?
-
Hello, I just looking for some info about copy files .atr or other files can be copied to real Disk on Indus GT Disk Drive. Is this possible?. If it is possible, how is the process? Comments, suggests i will apreciate. Thanks.
- 7 replies
-
- SIO2SD
- Disk Drive
-
(and 8 more)
Tagged with:
-
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