TI-994a How-To

[rhester72]

If you download my megapack (https://www.ti99iuc.it/web/index.php?pa ... Movp_JxeUk) and remove all the roms that are not a single file and all those with the TI99 BIOS included (with "FULL ROM" suffix") you'll get all the ones that work only if loaded as separate part.

What I'm really trying to get at is the why. Clearly all the ones affected have something in common - C and D ROMs. But not _every_ title that has C and D is affected, which is a bit odd. What distinguishes the members of that group in particular between those that work and those that require manual loading? If we can answer that, we've defined where the problem is (and likely how to fix it). This is an analytics problem - I've got it this far, but I can't determine why (for example) Donkey Kong is OK but Pac-Man isn't. That's critical and what I'm hoping we can collectively come to understand.

Rodney

[rhester72]

It looks like that python script is not correctly mirroring the ROM space.
Note that some games require mirroring across the ROM region.
If you only have 1 64KB C file, it should occupy the entire range.
If you only have 1 8KB C file, there should be 8 copies of it occupying the entire range.
If you have 1 8KB C file, and 1 8KB D file, there should be 4 interleaved copies of each (C,D,C,D,C,D,C,D) covering the 64KB range.

That last line is probably it. Investigating - and thank you!

Rodney

[rhester72]

@GreyRogue - if CROM is 4K, do I do it 16 times or do I do CROM+4K nulls 8 times? (i.e. are CROMs padded to 8K boundaries?)
SELF ANSWERING: Neither. CROMs are never really 4K.

What I'm REALLY asking about: The Extended BASIC CROM is 4K, but the DROM is 8K. How is it patterned throughout the 64K?
SELF ANSWERING: Bizarrely, at least if you're using the current MAME cartridge list ROMs.

Basically, the lower 4K of the 8K DROM gets appended to the 4K CROM, and the lower 4K of the CROM overwrites the lower 4K of the DROM, resulting in 8K CROM and DROM. Said another way, imagine cloning the CROM into two copies A and B and breaking the DROM in half. The first half of DROM is appended to copy A, the second half is appended to copy B.

Pictorally:

Code: Select all

Original CROM		Original DROM
4K A			4K B
4K [null]		4K C

Resulting CROM		Resulting DROM
4K A			4K A
4K B			4K C

These are, as GreyRogue indicated, then interleaved, so the entire 64K ROM space looks like:

8K CROM+8K DROM+8K CROM+8K DROM+8K CROM+8K DROM+8K CROM+8K DROM

Finally, simple case of nothing but a single 8K CROM...duplicate it 8 times for 64K in the ROM area (0000-FFFF), right? If I do that, titles that used to work (with 0000-1FFF being CROM and 2000-FFFF being nulls), like Miniwriter II and Munch Man II, now hang on start. OK, kids...if you're doing testing with MBX, turn it off when you're done.

All that remains now is to solve the mysteries of Mancala/Return to Pirate's Isle/TI CALC, but I shall save those for another day, as my brain hurts. LOL
MORE SELF-ANSWERING: Nothing to see here - if you interleave correctly (mirror CROMs 8x8K banks), at least the first two work perfectly!

[rhester72]

@Flandango Your guess on MBX support worked on all known original images! The NTSC support/aspect is also now spot on - thank you SO much!

[rhester72]

One note: Mancala, Return to Pirate's Island and Tutankham must be loaded with the following sequence:

1) Load System ROM;
2) Load .C file using C Load Menu;
3) Load .G file using G Load Menu;
4) Load .C file using D Load Menu;

Answered here:

If you only have 1 64KB C file, it should occupy the entire range.

If you do this, they work fine loaded as full ROMs. Your step 4 loads C into the odd 8K ROM slots, which is the piece of missing magic from pyTIrom.

Once I've worked out a couple things that irk me a bit about my Linux bash script to convert the MAME software list ROMs, I'll share so you can see the logic (if you can read bashisms - if not, I've done my best to explain Extended BASIC which was the only trying one for me, which hopefully combined with GreyRogue's information will explain everything).

[rhester72]

TI-CALC [PHM 3213] doesn't seem to work because of a port issue. See this from the MAME source (in src/devices/bus/ti99/gromport/cartridges.cpp):

Code: Select all

/*****************************************************************************
  Cartridge type: paged7
    GROM: up to 5 GROMs (sockets for a maximum of 3 GROMs, but may be stacked)
    ROM: up to 16 KiB (in up to 2 banks of 8KiB each)
    ROM mapper: 7000, 7002, 7004, 7006

    GROM space
    6000     77ff   8000     97ff   a000     b7ff   c000     d7ff   e000     f7ff
    |== GROM3 ==|...|== GROM4 ==|...|== GROM5 ==|...|== GROM6 ==|...|== GROM7 ==|

    ROM space
    6000                    7000                 7fff
    |                        |                     |
    |                        |===== ROM bank 0 ====|       write to 7000
    |                        |                     |
    |=== ROM bank 0 =========|===== ROM bank 1 ====|       write to 7002
                             |                     |
                             |===== ROM bank 2 ====|       write to 7004
                             |                     |
                             |===== ROM bank 3 ====|       write to 7006

    This is very similar to the MBX scheme, only that the bank switch is
    done by writing to the first words of the 7000 space. Also, there is no
    additional RAM.

******************************************************************************/

I assume this would require support in the RBF itself in the form of another Cart Type?

[akeley]

About the display on my consumer CRT TV set (via Direct Video).
-ver 210607 - PAL didn't reall work/ was buggy, filled the entire screen. NTSC was fine, filled the entire screen
-ver 210615 - PAL seems to work fine, tested on few games. It's really squashed vertically now, sort of like MSX display. NTSC is still fine, but now there are also are slight black bars on top and bottom.

OF course PAl being squished is normal, I was just wondering if it was really that much on a real machine. Also, how about NTSC? Did it fill the entire screen or are these bars normal?

Can post pics if need be.

[Flandango]

Unfortunately I don't have a CRT to test on but if you can post the pictures maybe I can figure something out.

As for TiCalc...Try this version attached below...
I can't get Old Dark Caves 2 to work right but I can sure as heck get TiCalc to work.

If using Mame roms, use phm3213_g3.bin as the Grom rom (G.bin) and combine phm3213_r1.bin and phm3213_r2.bin for C.bin
Dos Command:

Code: Select all

copy /B phm3213_r1.bin + /B phm3213_r2.bin phm3213C.bin

Select Paged7 as the cartridge type... Don't know any other cart that uses Paged7 banking scheme other than tiCalc.

[rhester72]

@Flandango

Good news - yep, Paged7 works (and TI-CALC is indeed the only cartridge I'm aware of that uses it), thank you!

Bad news - looks like there's some sort of regression (probably not from this build, but before it - not sure how far back), in that if you swap disks in a session, the second disk looks a little...off. For example, some reads get corrupted. I can supply a super specific test case if it's not immediately obvious what's going on.

[Flandango]

I can supply a super specific test case if it's not immediately obvious what's going on.

If you can I would appreciate it.

[rhester72]

@Flandango, ignore - I could have *sworn* I'd tested this case at least twice before, but it now reproduces on all versions of the core, suggesting pretty strongly it's not a regression (or likely even a core problem). More stuff for me to chase down, sorry about that!

Some other quick questions, if I may...sorry for coming off as the 'ungrateful feature-requesting user' (I've been on the other side of that fence MANY times), feel free to tell me to jump in a lake. Even better, tell me how/where to donate - what you've done for us already is WELL worth reward!

The easy ones (I think):

- Should the 99/4 system ROM/GROMs work? I thought they would, but it just hangs... (V2.2 works as expected, though, including lockout <G>)
- Any chance of being able to switch the 32K expansion on and off? It'd be especially helpful in tracking down GROMulated RAM-loading cartridges (without requiring being competent to disassemble TMS9900)

and the progressively less-easy wish-list ones that every developer dreads:

- How hard would it be to implement true mini-memory support, with the appropriate memory range loaded/saved automatically a la SRAM in other cores (where the contents are checked/dumped upon entry of the MiSTer menu)?
- Cassette (in pass-through WAV format, because HUGE nostalgia waves for that cassette sound!) read support (with media stop/play/rewind/ffwd controls)? Shoot, let's swing for the fences...write support? <G> (While the amount of cassette-only software is small, it does exist.)
- Any hope of expansion ROM (e.g. Arcturus) or huge ROM (Don't Mess With Texas demo, Dragon's Lair) support?
- p-code expansion card? LOL (Guessing this is super-unlikely, because as a kid it always seemed hyper-complex...but who knows, maybe it's just another mega-DSR in sheep's clothing?) I may be one of the only dozen people on earth that actually knows how to use one... *laughs*
- Other storage? (Myarc HFDC with IDE support comes to mind as a personal favorite, but there are other choices like CF...)

Ironically, I personally have little to no interest in higher-end VDP, Geneve, etc. - I was (and am) a bit of a purist when it comes to TI, for better or worse. If anything, I'd love to get some conversation started on the above and more...you've reignited my interest in the 99 more than anything that's ever come before, because it *genuinely* feels like the real thing! Thanks to EVERYONE who has contributed!

(And to everyone else, no, I haven't forgot to send up my fullROM set. I needed to test TI-CALC and have a few more small things to iron out, but it's coming very soon!)

[rhester72]

I can supply a super specific test case if it's not immediately obvious what's going on.

If you can I would appreciate it.

Well, I'll be damned. There is some sort of defect, but it's been present since your first build. It'll take me a bit to (re)create the test case so you know what to expect. Sorry for the confusion!

[rhester72]

@Flandango:

OK, steps to reproduce the problem that appears to be specific to disk swapping (only drive 1 tested), using the contents of the attachment cutthroats.zip:

1) Insert the Extended Basic ROM
2) Insert disk1.dsk into drive 1
3) Start Extended Basic and the disk will automatically boot (this takes a while)
4) When you see "Insert game disk 2 and strike any key", insert disk2.dsk into drive 1 (effectively swapping the disk - NOTE: I think it's this disk swap that triggers the bug) and press Enter
5) At the three --MORE-- prompts, press the spacebar and you will come to a ">" prompt
6) Type "$verify" (without quotes) at the prompt and press Enter
7) "When you see "Insert game disk 1 and strike any key", insert disk1.dsk into drive 1 (effectively swapping the disk) and press Enter (note that this stage _appears_ to pass without error, which I believe is validating the GAME1 file on disk 1)
8) "When you see "Insert game disk 2 and strike any key", insert disk2.dsk into drive 1 (effectively swapping the disk) and press Enter (and this stage will take a while before it errors out)

You will observe the following error:

What you _should_ see is "Yup. Game correct." (per this screenshot from Classic99):

screenshot_ok.png (1.85 KiB) Viewed 11082 times

The error produced on the MiSTer core (faked screenshot from Classic99 identical to MiSTer output):

screenshot_err.png (5.77 KiB) Viewed 11082 times

The reason I suspect it's related to disk swapping, specifically, is that if you take FIAD dumps of all the files from both disks (LOAD, LOAD1, BOOT, BOOT1, GAME1, and GAME2) and put them on an empty DSSD V9T9 disk image and use it instead (and just press Enter every time it asks you to swap disks), the verify works on the MiSTer core. I've now attached a DSSD of that very thing for comparison.

[tmop]

As promised, I've updated my TI99 MegaPack for MiSTer to support the new enhancement from @Flandango (disk support and Paged7 ROMs).

I've also inluded the last homebrews published in 2020/2021 (Escape North Korea, Dodger, Phenix, etc.) and the various disks for Adventure, TOD, Multiplan, etc.

Have fun!

Download from:
https://atariage.com/forums/topic/31265 ... nt=4847007

[rhester72]

@Flandango - if it helps, Deadline's even worse (and therefore perhaps better for troubleshooting) - it breaks on game start with the same disk read error, no verification process required. If it boots without errors (all the way through game start after disk 2), you've fixed whatever's wrong. =)

[Flandango]

@Flandango - if it helps, Deadline's even worse (and therefore perhaps better for troubleshooting) - it breaks on game start with the same disk read error, no verification process required. If it boots without errors (all the way through game start after disk 2), you've fixed whatever's wrong. =)

Thanks, I'll look into this one too. So far it's been slow troubleshooting since I don't know of an easy way to peek in the core to see what exactly is going wrong except through SignalTap...which for each simple change takes me 20 minutes to recompile and start testing again.

[rhester72]

@Flandango - if it helps, Deadline's even worse (and therefore perhaps better for troubleshooting) - it breaks on game start with the same disk read error, no verification process required. If it boots without errors (all the way through game start after disk 2), you've fixed whatever's wrong. =)

Thanks, I'll look into this one too. So far it's been slow troubleshooting since I don't know of an easy way to peek in the core to see what exactly is going wrong except through SignalTap...which for each simple change takes me 20 minutes to recompile and start testing again.

Yeah, I figured as much. If there's anything at all I can do to help, please advise. This is a tough one.

[tmop]

@Flandango.

Some other feedback for the latest version of the core:

- Old Dark Caves now seems to work fine. I've tested with both versions I have (with fast and normal loaders). I've mounted first the dsk image, then run a full rom with XB. However, I was able also to run it correctly mounting the disk after having loaded XB and it worked;

- Display Master: it's working fine now;

- My version of Deadline (on MegaPack) works fine. It's on a DSSD disk and uses the V1.3 of the interpreter. The "$verify" commands was ok. Not sure if this could help the troubleshooting;

- The companion disks for Multiplan and TI Writer work fine;

- The Tax Investment Record Keeping seems to work fine (I've initialized its db disk);

- I've tested more than 40 roms that I had ro rebuilt with disk support and they seems to run fine;


I've noticed that the TURBO menu now is not working. To check just load a BASIC program, LIST it. Then set the Turbo to ON and try to LIST the program. The TURBO was working fine on latest official core.

[pgimeno]

@Flandango - if it helps, Deadline's even worse (and therefore perhaps better for troubleshooting) - it breaks on game start with the same disk read error, no verification process required. If it boots without errors (all the way through game start after disk 2), you've fixed whatever's wrong. =)

Does it work if you first remove the disk (by pressing Backspace in the file browser) and then select the new one?

[rhester72]

@Flandango - if it helps, Deadline's even worse (and therefore perhaps better for troubleshooting) - it breaks on game start with the same disk read error, no verification process required. If it boots without errors (all the way through game start after disk 2), you've fixed whatever's wrong. =)

Does it work if you first remove the disk (by pressing Backspace in the file browser) and then select the new one?

I thought you might be on to something - but no, it makes no difference at all.

It does, however, seem to have -something to do with perhaps specific sector locations or something? Consider this: Boot disk 1, all is well (which means it presumably read every requested sector correctly). It asks for disk 2, you insert it and continue, it blows up - so that means a bad read on disk 2. However...reinsert disk 1, restart XB (*not* the core!), and boot again...and the cycle repeats, which means it can *consistently* read disk 1, suggesting the issue isn't _really_ about disk swapping but something specific about data locations *on the disk itself*.

I'm going to experiment with this theory like so: Create an artificial SSSD image with the 'header sector' valid for a blank disk, and every subsequent sector from 0 onward set with the first byte to the sector number (or closest equivalent) and every other byte set to 0x55. If you then attempt to do a sector-level copy of that disk from with MiSTer itself, theoretically, if there are any areas where the read (or write) isn't acting as expected, it should be readily identifiable on the copy. *shrugs* It's a theory...don't have much else better to do trying to chase this down.

[rhester72]

Hrm...I think I've blown my latest theory. I left Disk Utilities 4.2 running a destructive test on a SSSD in loop mode overnight without a single failure, so unless it's an alignment problem, sector-level reads and writes both appear to be just fine.

I'm still going to attempt a known-hand-constructed-bad sector copy to see what the result is, but I expect it will work perfectly...and then I'm not quite sure where to look. If it's not swapping and it's not the image, what on earth is going on?

[Flandango]

I believe I figured out the issue. I'm running through a bunch of tests, once I have 100% repeated success, I'll post it.

[Flandango]

Ok. I have been using Old Caves, Cutthroats and Deadline as my test cases for the floppy issues. I got them working 100% of the time on my rig.
I had to tweak clock speeds so VGA/CRT video may be off especially for PAL (it's reporting as 50.2HZ) so if anybody is testing/playing on a pal CRT/TV, let me know how it goes.

[rhester72]

Can you elaborate on what the problem was? I'm intellectually VERY curious.

[Flandango]

Timing. The floppy drive (not the controller) is passed the clock frequency used by the core (in this case it was 42.666.....) so it can do some calculations.
Unfortunately, during compile time, the clock was adjusted slightly from what was specified.
Normally it's not an issue if you the floppy drive was actually running off that clock, but it was using it to make various calculations which in the end it was off by a few pulses after millions.
And apparently some software is VERY picky on when it wants the data. If it doesn't get it within the specs it aborts.
So in the end I had to find a core frequency that would make the System clock and all the derived clocks happy, and not get too adjusted by the compiler (Quartus) that throws off the floppy drive.

[rhester72]

Wow. I thought the 2600 racing the beam was bad...that's shockingly bad!

There's no way to key the floppy off a fixed multiplier of the system clock to keep them in sync, or at least have both similarly maligned at compile? (Again, sorry for the ignorance - and causing all this trouble!)

[rhester72]

Hrm. Your mention of the number of revolutions keyed me on to something.

Nearly every V9T9 image I have has fixed interlave - 0 1 2 3 4 5 6 blah blah blah, which is NOT ideal for the stock controller.

Is anyone aware of software that will make a copy of a (virtual) floppy and re-interleave it on the receiving side? TI native, Linux manipulating dsk images, whatever - anything capable of such a thing. I'm keenly curious in seeing if correcting interleave on a virtual floppy will actually improve clock load time on MiSTer (as it would on real hardware), because (for example) loading Deadline takes a *LOT* longer than I'd expect on actual hardware.

[rhester72]

@Flandango - you're going to hate me. Something's still slightly off.

Deadline works now, but trying to format a SSSD (tried with DM3) ends with "DISK ERROR 43, LOST DATA ON PRINT" after a bit. (I've literally never seen that error in my life, I don't even know what it means!)

[Flandango]

Not sure, looking into it. Disk Utilities worked fine for me but Disk Manager doesn't so testing it now.

[rhester72]

Hrm. Your mention of the number of revolutions keyed me on to something.

Nearly every V9T9 image I have has fixed interlave - 0 1 2 3 4 5 6 blah blah blah, which is NOT ideal for the stock controller.

Is anyone aware of software that will make a copy of a (virtual) floppy and re-interleave it on the receiving side? TI native, Linux manipulating dsk images, whatever - anything capable of such a thing. I'm keenly curious in seeing if correcting interleave on a virtual floppy will actually improve clock load time on MiSTer (as it would on real hardware), because (for example) loading Deadline takes a *LOT* longer than I'd expect on actual hardware.

Self-answering...nope. The limitation lies in the v9t9 format itself (unlike PC99), where there's no means of capturing interleave information of any kind. It's not optimal, but it's not clear to me whether that has any real impact on (low-level) emulation performance with respect to floppy read/writes. Doesn't much matter either way, nothing can be done to correct it short of choosing another format (for little real-world benefit).

Also, the only way I found to actually do a copy that changes interleave is to format the target with MDM5 specifying interleave, then doing file-level copies from source disk to the new interleaved one - again, talking about physical hardware or PC99-format-supporting emulators, NOT v9t9-style images. If you need to do a sector-level copy, from what I can tell, you're out of luck trying to adjust interleave.