Tursi

I wish THE Doctor, hehe. Hehe.. if you just want the synth to speak crap, just send it a broken LPC string, probably don't even need SPGET.

Yes, it does. So does the Colecovision and (though the chip is a little more advanced) the MSX. It's actually pretty standard for trackers to use their own GUIs, I guess you never messed around with MOD files. Doesn't make it any easier to get the hang of, but the point of the interface isn't loading and saving files, but composing music. To that end it functions like most traditional trackers. I'd say it's substantially better than nothing. The ability to import VGM and export in the somewhat size-reduced EPSGMOD format is actually a benefit if you want to use tracks from other systems - there are thousands of VGM files recorded from almost every game released on SMS (and Genesis, but you won't get much out of those files). The downside is VGM is fairly wasteful of space, since it records every change sent to the sound chip (meaning, for instance, a bell sound has every volume change recorded, while the native format would only need a single note). The MOD and MIDI imports are also disappointing, the resulting files are nearly useless most of the time. I had planned to write my own converter for them at some point as I have some files I need to convert, and I want very simple changes (like storing drums only on the noise channel, not whatever happens to fall there... ). Again, dunno when or if that will happen. The music composition itself is quite good, though, offering a lot of variety in the sounds produced. It has full control over the noise channel, better-than-ADSR keying on the waveforms, and vibrato and modulo for free. Most importantly, a working tracker is not a simple thing to build, plus it apparently supports MIDI input, suggesting that you can compose your tunes with a MIDI keyboard.

Actually, Matthew, if you just support segments (using the TI naming scheme or something else), that's really what they are for. The idea of segments is just that each segment has its own address counter, and you switch between segments freely in your code. Then when you assemble or link, that's when you tell the computer what address to base each segment at. This makes it easy to write code that works both in RAM and on cart, you just change the data segment and program segment addresses around.

I could probably add a new ROM image type for that once it's proven to work on hardware. The concept is simple enough.. just have to make sure there's no extra hardware required that would affect emulation.

hehe... definately. But there's a practical reason, too. Some modern systems (like my old projector, grr) can't handle the 262 line progressive scan signal the TI, and other classic systems of the day, outputs. Specifically in my case, the bottom half or so of the screen would jump and flicker badly. This happened with my Atari 2600, ColecoVision, Genesis and TI. So a more modern output video signal keeps the machines running on modern displays. Just not sure which approach I'll take. Since my solution is reasonably years out yet, not much point planning in too much detail.

Any reviews pending of Mario? The shipping issues kind of overshadowed any talk about the game.

Yes there is, actually... But it's way, way, way down on my massive TODO list. :/

It looks fantastic! Remember that when speaking in XB, your program is essentially hung, it can't do anything else. As for the rest of the problems with speech.. slowly. Will get there eventually. Speech wouldn't be implemented in the half-assed way that it is at all if a certain 'Doctor' on the old TI list hadn't gone on a rant one day.

Well.. that, and the fact that the loader doesn't support any of the segments except the program segment, which is the default anyway. Having actual segment support would be nice for some instances - like building ROMs.

Now you've forced me to go look up which is the answer. Columns 6 and 7 uniquely scan the joysticks, and no keyboard rows, so it is possible to read the joystick distinct from the keyboard. However, KSCAN unit 1 and 2 reads both 1/2 the keyboard AND the associated joystick fire button. The fire button returns a code of '18', which matches Q on joystick 1 and Y on joystick 2. KSCAN is a little bit complex, but some interesting points. If fire is pressed, the keyboard unit scan is skipped (mode 1 and 2, that is), so the joystick can override the keyboard. The same indexing code is used to get the final return value as for keyboard scan. So any app that calls KSCAN will be unable to distinguish the fire button from Q/Y. Two places even. Under the keyboard section: And under the configuration reference, joystick: Moving on... I ported the ePSGMod format to the TI... my code is here: http://harmlesslion.com/software/psgmod The original tracker is here: http://www.kontechs.de/product?name=mod2psg2 And the sample program is built into Classic99 under Cartridge->Apps->EPSGMOD Sample SPECTRA has also built the player in. However... the author hasn't supported the tracker well.. he gave me the 2.05 code years ago and still hasn't updated the tracker itself on his site. That, plus the license terms, has me thinking we might want to just roll our own. The attraction of this tracker was the ability to cross-pollinate with the Master System crowd (and hell, Coleco and MSX can use it too), but it doesn't seem to be heavily used. Besides Shiru's (amazing) tracks, I've seen very little else.

Had a quick play here at work... looking good! Very nice with a fast response time like that. Getting wrapped up by the spider is oddly creepy...

It's been Tab consistently for 15 years now. Note that in most games, "Q" also responds for Joystick 1, and some games map an alternate key (like period) as fire, but this isn't Classic99's fault. If you are using the keyboard for joystick emulation, it's arrow keys and tab. It's not configurable today. This is documented in Classic99.txt. I know you guys bitched me out about my docs but "pretty" ones are coming, then there will be no excuses.

ZomBXB - Tursi ZombXB.zip

You say you have it already, but as a suggestion.. when you have tons of ROM and little RAM, use the ROM. It might be helpful to just predefine the screens in the ROM itself, then you can just copy right out of them when you need to erase.

Classic99 doesn't read any of the custom formats that Cory created because he refused to share details of them, and they were too complex to unwind in an evening. It is unfortunate because his cartridge format is very nice. We will have to repeat his work and add description, manual, and cover picture fields to the MESS RPK format instead (the nice part of using XML is we can do that ). The cartridge format that Win99Asm outputs does appear to be a proper TI-formatted cartridge image.

Filenames are not case sensitive in Windows (normally), so the uppercase C shouldn't matter (existance, yes, case, no). I've just tested here to make sure lowercase works, too, and it seemed okay. Otherwise looks good!

The crash turned out to be an uninitialized critical section.. Seven reports it in the debug log then just continues merrily along, while XP (and probably older versions) crashes. Thanks to everyone for the bug reports, and Mark for testing for me. Now I know how to check for these before I release (since even under the debugger they get ignored!!) The fixed version (340a) is up and ready to go: http://harmlesslion.com/software/classic99

GAH! 2 minutes to 4am, I am shutting down the computer NOW!!!

Since a lot of people here are using it, I'll note that Classic99 340 is up now at http://harmlesslion.com/software/classic99. You'll find the full changelist there but I snuck in a few things people here asked for, like the window sizing options, better debugger support, and plenty more.

Funny thing was, that was my first goal for this contest, but I assumed we'd be able to poke in a little assembly support, so when that was nixed I dropped it. This is another fine looking entry! You guys are all pretty good artists!

Bah... wimps. I made sure every line in my program could be pasted into the normal line limit, not one is over 141 chars. Was tempted to use the line extension tricks in a few places... what did annoy me was "line too long" on lines that were less than the max input length (got that on some of the data statements, since it counts tokens and not characters )

I don't even guarantee 1x right now, not going to promise 2x,4x, etc. CPU overdrive is your best bet... System Max still hits the real PC hardware too hard, causing problems that range from slow response time to outright crashes (depending on the quality of your drivers). It's another fix that's waiting for the fixes to the system timing that I have planned. Of course, the trick is that CPU overdrive only speeds up the CPU, while system maximum keeps everything at the same ratios but speeds up the whole system. If you want to speed up the CPU by a fixed amount, the Options menu allows you to adjust from 0%-200% for the normal speed.

Hehe... meant to mention all my tricks in the first post. Using ON ERROR let me save some time in the loops to read the data... by ordering the data so that the end of a block would cause an error to occur, and having that just go to the next block, I didn't need to hard code the size of the char tables or write code to look for a terminator. Of course, when there were real bugs, they were hard to track down, as they'd just appear as characters not being redefined. (Or in a few cases infinite loops where it kept branching back to the last ON ERROR target).

Kind of silly to start a new post for an update, but I was flooding the main one. Here's my update to Zom-BXB... I took the Farmer Owen and his Zombie-filled fields motif and ran with it (except I am not good enough to make a nice field-like backdrop like some of you!) I've also improved the frame rate quite a lot (I feel), added a difficulty curve (though it's a little slow to kick in), and upped the graphical resolution. (The only reason I did Magnify 2 sprites the first time around was because I was saving memory - not necessary.) Although I used a lot of it for fluff, the game's up to 30 lines of code and 10 lines of data. I never would have thought I'd spend so much time on a 40 line program. But here you go... Also updated the story, and the archive includes the farmer pic (it's adapted from some old clipart I have on supposedly royalty-free CDs ), and the slightly 'commented' source code in text form. I did a couple of unusual tricks to speed it up. Besides lots of shuffling around of stuff in the main loop, I removed random numbers completely by pre-generating a handful and dropping them in an array. I experimented with some advanced theories, like turning off the console interrupt with a CALL LOAD (and even running the sound generator manually), but that turned out to have a rather small difference in speed here. Unless sprites are actually MOVING, stopping the interrupt doesn't give much CPU time back. (In this version of XB.. in the early ones it did.) ZombXB.zip

Damn, if someone actually could make hand-carved cartridge shells, that would be amazingly awesome.