Don't Mess With Texas Demo on Flashrom 99

[Vinnie D.]

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?

[+arcadeshopper]

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

[Asmusr]

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

[Vinnie D.]

Thanks. I didn't know there was a bigger RAM expansion out there, which is why I was confused about this.

[jrhodes]

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

[Asmusr]

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

[HOME AUTOMATION]

"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)

[Vinnie D.]

 

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.

[+arcadeshopper]

  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

[+arcadeshopper]

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.

[Omega-TI]

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...

[Asmusr]

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.

[Tursi]

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.

[+arcadeshopper]

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

[+arcadeshopper]

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

[+jedimatt42]

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

[Tursi]

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.

[RXB]

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