Tursi

Ah... yeah, that's probably it. Changing the CRU setup in the middle of a scan wouldn't be helpful.

That's kind of interesting, though. Does it offer any kind of crash log that suggests WHY it crashes? Or does it just not like 32-bit apps? Does a 64-bit build behave any differently? (Note: lots of build warnings in this - no promises for long term use. Just a test.) Classic99x64_nosupport.zip

I knew I had this.. I found it while browsing some old disk images. It was on a disk of music files I'd accumulated, and linked together to make a XB music box of sorts... Basic_MUSIC.DSK

No, the TI keyboard is literally just a grid of switches. They don't trigger interrupts, so interrupts don't need to be enabled. There's no storage and no caching of status. The KSCAN function literally reads the keyboard by enabling each column, and seeing if any rows on that column are pressed - this is why KSCAN takes a fair bit of time to run. It also means you only know the state of the keyboard at the exact time that you scan it. I don't see in a quick scan why interrupts should interfere with KSCAN, but all console software in the TI runs on the assumption that interrupts are normally disabled. When you violate assumptions in other people's code, you tend to get bugs.

ROM or GROM Cartridge header is documented nicely at Nouspikel.com: http://www.unige.ch/medecine/nouspikel/ti99/headers.htm#header summary (edit: huh, guess it's not Nouspikel.com anymore )

Dead modulator wasn't all that uncommon, I know a few people switched from RF to composite video rather than get a new one. Also, dumb question, but you slid the tv/computer switch on the modulator, right? In addition to switching the video, there's a power switch inside the box, so it won't do anything if it's not on.

GROMs only have one address - even GRAM uses the same address counter, so there's only one thing to save/restore. However, Editor/Assembler doesn't require you to save the GROM address to return to it. The GPL interpreter /generally/ assumes that it needs to set the GROM address for every new instruction. The problems mentioned above are specific to those DSRs. (Edit: and frankly - I wonder how true it is. They corrupt the GROM address, okay - but who cares? It's possible those guidelines were written before the GPL interpreter was finished? And doing what, anyway? Just a KSCAN, right?) As for BLWP @0 - this does all the same initialization and startup that turning on the console or resetting does -- but no reset pulse is sent out to the hardware. Again, generally this is not a big deal on the 4A, since most of the hardware doesn't do very much on hardware reset, but it's worth noting that it's not exactly the same.

There aren't very many incompatible programs -- and frankly these days, if you come across a deal breaker we can probably fix it. You can consider installing a switch as well, that will let you go back to the original timing, which solves the incompatibility issues. All that said, I got tired of the increased complexity and ... well, that PDF /is/ my 8-bit version. But when I was using my TI as my sole console, I really appreciated the speed up.

That would be extremely CPU demanding, and probably wouldn't work very well. I don't know how many changes you can get per scanline, but likely only a couple. It's easy enough to find out though, it's only a handful of instructions to write the background register and increment in a tight loop. You don't need delays on the VDP registers. If you reset the loop on the NMI, then you should be able to get a stable picture and can zoom in to see how many changes per scanline you get. My bet is 2.5. The trick of changing data on a certain scanline was used on the TI in the Don't Mess With Texas demo. See starting at 5:22, three effects. Usually there's a little slop in detecting either by sprite collision or 5S, but Rasmus pulled off some really stable effects there.

That's a system seller there!

I've now finished this as far as the features I intended to code, and am moving on. https://github.com/tursilion/vgmcomp2/blob/master/readme.md

Well... they aren't standalone devices - all the ones purchased ended up inside machines. You're more likely to find a machine with an F18A on EBay than a standalone F18A. That said, you could go post in the Wanted forum here. Between MSX, Coleco, TI and Arcade, a lot of the people who bought them are on AtariAge, but they aren't constrained to the TI subforum.

Comp.sys.ti is still active?

My instinct is no... I am pretty sure the 8-bit bus still sees activity even with 16-bit accesses (just that the multiplexer doesn't kick in). I would have to double check (but am feeling lazy), but I thought the VDP was attached to the 16-bit side of the bus anyway... The 9900 has the ability to suspend for external DMA masters, but TI locked that pin down instead of exposing it to the expansion port. Not that that's exactly what you had in mind either.

Classic99 will also read and write the track dumps, though I don't guarantee the track dumps will be useful anywhere else after writing. Sector dumps are where most of the TI images standardized. There were very few (if any?) TI disks that required a track dump to operate, and some research years back cast doubt whether the inter-sector data on PC99-originated dumps was correct anyway.

She can't believe the 16-bit POWA!

That's nice to see. Trend Micro made it a mission to change the rating of my own website.

Classic99's DSR does not attempt to replicate a TI Disk Controller. (Edit: since the emulator includes the real TI disk controller, you can also test that. But don't use the Classic99 DSR to guess how a TI controller works. )

Elvira, of course

(Now with much improved level balance between the FM channels as well as between the FM and SN.)

Finally back on this task, and tonight I pushed up something I've wanted forever, and one of the reasons I started this update - md2psg. MD is MegaDrive, aka the Sega Genesis. MegaDrive VGMs can now be read and output in a format loosely compatible with the PSGs used here. It's far from perfect. I think the envelopes must be working, but honestly I am having a lot of trouble understanding how the MD generates the final volume on a channel at any given time, since emulators work at the sample level. What I have seems good enough as a starting point, anyway. Of course, with 6 FM channels PLUS a TI PSG in there, the task of getting 10 channels playing on a TI is left as an exercise for the reader. But that's the point of this whole toolchain - to provide the tools needed to tweak and manipulate this sort of music into something usable. I've posted a video here with a number of conversions. Since the video was recorded I fixed the desynchronization issue that broke Scrap Brain Zone, and also rebalanced the volumes by default a bit, so I think the starting point is pretty decent. It also converts the tune in one pass for both chips - in the video you'll see me running the two converters separately. https://open.lbry.com/@tursilion:1/VgmComp2---Sega-Genesis-to-SN-Example:f Of course, the files are are pushed up to Github with binaries and docs in the dist folder. It's nearly there, just a few tools left to build (and another player if I decide I want to do it... waiting till I get that far before I delete it )

You can renumber your program in BASIC or XB with the "RES" command. With no arguments, it will start at 100 and increment by 10, or you can specify it as "RES start,increment" (like RES 50,5) But to get it out of Classic99, just use the LIST command to a device. LIST "CLIP" will list it to the Windows clipboard, and then you can paste it into your favorite text editor. If DSK1 is a file folder, as shipped, you can list to a Windows text file with LIST "DSK1.?W.FILE.TXT" (there are shorter ways but "?W" will make it work regardless of configuration.) If you have a different drive set as files you can select it instead of DSK1. If you are using disk images, obviously this won't work.

RET was a standard replacement for B *R11. I thought that Editor/Assembler first used it, but when I looked in the manual, EA actually used "RT". Suffice to say whatever assembler SPECTRA used supported RET.

.OBJ is usually an Editor/Assembler #3 object file... load with Editor/Assembler option 3. Twitch won't allow a direct video link cause they're dummies. So you have to click. https://www.twitch.tv/videos/757924510

The local UHF station in my grandparent's town of Peachland, BC, clearly used a TI for the community messages channel (back in the 90s). From the font to a double-size magnified sprite of Mr Bojangles dancing across the top of the screen, I recognized it instantly. Sadly, no pictures.