Vinnie D. Posted August 31, 2018 Share Posted August 31, 2018 Simple question. I'm running a TI-99/4A with a 32K sidecar, speech synth with power pass through mod, and a Flashrom 99. When I downloaded the Don't Mess with Texas demo I noticed that it included a bin file which I assumed would run on Flashrom 99, since it originally runs from a cartridge. Ultimately though when I load it on the SD card it will never appear in the file list when the system comes up. Plenty of other software runs this way, but not DMWT. Is this even possible? I'm assuming if they bothered to release a .bin version it would be able to run somehow, so it seems strange that it wouldn't even be recognized by the Flashrom 99. Is it actually a GROM? Emulator only? Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted August 31, 2018 Share Posted August 31, 2018 you need a finalgrom99 to load it, or a 512k cartridge board.. The file>32k then it won't fit in a flashrom99 which only has 32k space Quote Link to comment Share on other sites More sharing options...
Asmusr Posted August 31, 2018 Share Posted August 31, 2018 (edited) I'm assuming if they bothered to release a .bin version it would be able to run somehow, so it seems strange that it wouldn't even be recognized by the Flashrom 99. Is it actually a GROM? Emulator only? I am one from the team behind the demo. As Greg wrote you need a bigger cart or a disk drive to load the demo. There is no way this would fit into the 32K of the Flashrom 99. The demo is not GROM or emulator only. Edited August 31, 2018 by Asmusr Quote Link to comment Share on other sites More sharing options...
Vinnie D. Posted August 31, 2018 Author Share Posted August 31, 2018 Thanks. I didn't know there was a bigger RAM expansion out there, which is why I was confused about this. Quote Link to comment Share on other sites More sharing options...
jrhodes Posted August 31, 2018 Share Posted August 31, 2018 (edited) I think you're still a little confused. The finalrom uses ROM memory. The finalgrom supports a memory type called GROM, and has nothing to do with the 32k memory for the console. It is not that you need more memory for the console, but the right type of memory for the cartridge port. GROM's are the type of memory in most commercial first-party TI carts. The finalrom cart does not support this. To counter this, the TI community made the finalgrom, which supports files intended to be loaded to this type of memory. There is a bigger memory expansion for the console, in the form of the SAMS card, a.k.a "superAMS" card. Edited August 31, 2018 by jrhodes 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted August 31, 2018 Share Posted August 31, 2018 (edited) Thanks. I didn't know there was a bigger RAM expansion out there, which is why I was confused about this. You don't need a bigger RAM expansion, but you need a bigger ROM expansion if you like. ROM cartridges provide memory as 8K pages. Your FlashROM99 can only provide 4 pages = 32K. FinalGROM99 can provide 64128 pages = 5121024K. Red boards and Uber GROm boards can also provide 64 pages. Edited August 31, 2018 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted August 31, 2018 Share Posted August 31, 2018 "FinalGROM acts as a 1024 KB ROM cartridge with 128 banks of 8 KB each." The "Don't Mess with Texas" demo runs fine for me. the .bin file is 512K in size! (set as rom) 1 Quote Link to comment Share on other sites More sharing options...
Vinnie D. Posted August 31, 2018 Author Share Posted August 31, 2018 Asmusr, on 31 Aug 2018 - 3:27 PM, said: You don't need a bigger RAM expansion, but you need a bigger ROM expansion if you like. ROM cartridges provide memory as 8K pages. Your FlashROM99 can only provide 4 pages = 32K. FinalGROM99 can provide 64 pages = 512K. Red boards and Uber GROm boards can also provide 64 pages. Hrm. Makes sense. Guess I should have shelled out for a final GROM instead of a flashrom 99, but at the time I didn't know what you told me, so I'd assumed running GROMs was the only difference. At least the mystery is solved. I'll have to look into an upgrade of either a final GROM or just get a nanoPEB and run the disk version. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted September 3, 2018 Share Posted September 3, 2018 Hrm. Makes sense. Guess I should have shelled out for a final GROM instead of a flashrom 99, but at the time I didn't know what you told me, so I'd assumed running GROMs was the only difference. At least the mystery is solved. I'll have to look into an upgrade of either a final GROM or just get a nanoPEB and run the disk version. except! the disk version will not work on the nanopeb, it requires SAMS which requires a expansion box.. best bet is to get a finalgrom or just buy the cart from me at arcadeshopper.com read the readme i posted and I guess it will work with 32k..but not as well.. nano's aren't being produced or sold as of late I haven't seen any.. better to get a sidecar32k and tipi.. Greg Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted September 3, 2018 Share Posted September 3, 2018 here's the README.TXT from the demo.. Hardware requirements: Best:Console with 32k and ROM cartridge-loads and runs smoothly from ROM Second Best:Console with 512k SAMS and DSSD floppy and XB or Editor/Assembler-pre-loads entire demo from floppy to SAMS-runs smoothly from SAMS RAM Third Best:Console with 32k and DSSD floppy and XB or Editor/Assembler-Demo will run, but disk access between scenes will interrupt Running: Cartridge (32k required):- Plug in the cartridge and select DEMO from the program list- demo8.bin is a non-inverted 512k cartridge image for hardware or emulation- ti99demo.rpk is a MAME/MESS cartridge for use with MAME or MESS Disk with 512k SAMS and Editor/Assembler:- Insert demo.dsk (DSSD) and run EA#5 "DSK1.SAMSDEMO" Disk with 512k SAMS and Extended BASIC:- Insert demo.dsk (DSSD) and start Extended BASIC- LOAD program will offer a choice between 32k and 512k version, select 512k Disk with 32k and Editor/Assembler:- Insert demo.dsk (DSSD) and run EA#5 "DSK1.DEMOA" Disk with 32k and Extended BASIC:- Insert demo.dsk (DSSD) and start Extended BASIC- LOAD program will offer a choice between 32k and 512k version, select 32k Bonus: For continuous run (such as at shows), leave Alpha Lock UP and the demo will repeat when it reaches the end. Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted September 3, 2018 Share Posted September 3, 2018 Huh? You might consider cramming in a TIPI version somewhere near the top of that list. Things simply run faster from TIPI's emulated drives than from Real Iron... and there is no size restraint. Someone could ZIP up a version, possibly to run under a specific sub-folder with a targeted loader. Just a thought... Quote Link to comment Share on other sites More sharing options...
Asmusr Posted September 3, 2018 Share Posted September 3, 2018 Huh? You might consider cramming in a TIPI version somewhere near the top of that list. Things simply run faster from TIPI's emulated drives than from Real Iron... and there is no size restraint. Someone could ZIP up a version, possibly to run under a specific sub-folder with a targeted loader. Just a thought... I far as a remember the disk loader is using sector IO in order to fit everything onto a 180K floppy, so a new SAMS loader would have to be written for the TIPI. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 3, 2018 Share Posted September 3, 2018 The loader will try sector I/O, and then fall back onto records if sector I/O is not supported. It should, in theory at least, "just work". I wanted it to work over the HDX at the time we did it, so I tried to be compatible as was reasonable. The only requirement for making it fit was packing all the separate files into one large data file, cause the directory entries were eating kilobytes of disk space. To determine if sector I/O is okay, we first read the number from the "DSK1" part of the filename, and it must be 1-9. Then we sector read from sector 2 onwards until we either find an FDR for "DEMOB", or a sector that doesn't look like an FDR (testing offset 10 for >0000, which shouldn't happen). Next we make sure there's only one cluster, as the sector reading code doesn't support a fragmented file. Finally it tries to actually read the first sector of the file, and verifies the first two bytes. If any of that fails, then it falls back to normal 128 byte record reads. 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted September 3, 2018 Share Posted September 3, 2018 The loader will try sector I/O, and then fall back onto records if sector I/O is not supported. It should, in theory at least, "just work". I wanted it to work over the HDX at the time we did it, so I tried to be compatible as was reasonable. The only requirement for making it fit was packing all the separate files into one large data file, cause the directory entries were eating kilobytes of disk space. To determine if sector I/O is okay, we first read the number from the "DSK1" part of the filename, and it must be 1-9. Then we sector read from sector 2 onwards until we either find an FDR for "DEMOB", or a sector that doesn't look like an FDR (testing offset 10 for >0000, which shouldn't happen). Next we make sure there's only one cluster, as the sector reading code doesn't support a fragmented file. Finally it tries to actually read the first sector of the file, and verifies the first two bytes. If any of that fails, then it falls back to normal 128 byte record reads. I'll give that a try Sent from my LG-H872 using Tapatalk Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted September 4, 2018 Share Posted September 4, 2018 I'll give that a try Sent from my LG-H872 using Tapatalk So far no love on either TIPI sidecar/32K or TIPI PEB with AMS. Both lock up after the initial load. so it looks like it's loading the file ok, and then the records from the DEMOB file then it crashes hard.. Greg Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted September 4, 2018 Share Posted September 4, 2018 Clearly Tursi is describing low level >10 sector IO. But just to be clear, there are places where direct input and direct output routines are documented as 'sector' io. When I say that TIPI doesn't support sector io, I actually mean just the sector io (>10) routine. I support direct input and direct output routines. There might be bugs, but I support them. Direct Input: you get to specify a unit number, and file name, and a range of 256 byte blocks. Sector IO: you have to read the directory sector to find the file's sectors, and then read those sectors. -M 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted September 5, 2018 Share Posted September 5, 2018 Yes, I'm talking about the actual raw low level disk sector I/O call, but if it returns a failure code or can't even be found in the DSR, the code falls back on record reads (IF/128, IIRC). There was no advantage to reading the file sector-by-sector, it was the overhead of open/close I was trying to avoid, so to improve compatibility if I needed to OPEN the file anyway I just used normal record access. It's a shame it crashes... maybe I'll soon get a chance to play with it. Unfortunately I tested only with Classic99 (disk and file access) and a real TI disk controller (which obviously supported the sector reads). I pushed my huge project into merge request yesterday and just have a little testing to do before the next big deal. 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted September 6, 2018 Share Posted September 6, 2018 (edited) The loader will try sector I/O, and then fall back onto records if sector I/O is not supported. It should, in theory at least, "just work". I wanted it to work over the HDX at the time we did it, so I tried to be compatible as was reasonable. The only requirement for making it fit was packing all the separate files into one large data file, cause the directory entries were eating kilobytes of disk space. To determine if sector I/O is okay, we first read the number from the "DSK1" part of the filename, and it must be 1-9. Then we sector read from sector 2 onwards until we either find an FDR for "DEMOB", or a sector that doesn't look like an FDR (testing offset 10 for >0000, which shouldn't happen). Next we make sure there's only one cluster, as the sector reading code doesn't support a fragmented file. Finally it tries to actually read the first sector of the file, and verifies the first two bytes. If any of that fails, then it falls back to normal 128 byte record reads. I worked on a SAMS LOADER/SAVER for 4 months using every type of file format i.e. IF255 , IF254 , IF192 , IF128 , IV128 , and Program Image up to max of VDP memory of 14K blocks. I even tried a SECTOR IO of 4K=16 sectors per 4K SAMS 4K page. After all that I reverted back to Program Image from 8K (2 SAMS 4K pages) down to 1 SAMS 4K page. Yes this meant more files on disk, but now you could load them into any page any time. I wish good luck to anyone that creates a better loader....believe me I tried every option I could dream up. Edited September 6, 2018 by RXB Quote Link to comment Share on other sites More sharing options...
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.