Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: utz on March 01, 2013, 11:08:54 am
-
Want to make chiptune music on your calculator? Well, now you can.
(http://irrlichtproject.de/pix/houston.png)
Download Houston Tracker 0.3 (http://www.irrlichtproject.de/downloads/houston.zip)
Includes TI82/83/83+/84+ binaries and offline manual.
Source code (https://github.com/utz82/HoustonTracker) new
Website (http://www.irrlichtproject.de/houston)
Sound demo (http://soundcloud.com/irrlicht-project/houston-tracker-for-ti-82)
Sound demo for version 0.2 (http://soundcloud.com/irrlicht-project/houston-tracker-for-ti-82-1)
This is an early beta. Please post bug reports, feature requests and other feedback in this thread, or send me a mail (see the manual for my address).
Features:
- 1-bit PFM and XOR sound(similar to various ZX Spectrum beeper routines)
- 2-4 tone channels + 2 interrupting drum sounds
- (Pseudo-)Stereo sound (channels hardpanned l/r)
- Compact editor+player
- Linear song data, no patterns
- Multiple sound routines
Not done yet:
- Internal compression (working on it)
- Dumping/Loading song data via PC soundcard
- TI85/86/73 ports
The editor is very simple and should be intuitve to use if you're familiar with the concept of trackers (https://en.wikipedia.org/wiki/Music_tracker). However it uses hexadecimal input instead of note names. Why on earth, you may ask? Well, as you know there are only about 27K of RAM available on the TI82, and there are no fancy flash carts or sd card readers. So I tried to keep the editor as lightweight as possible, and max out space for song data instead. Implementing a note table lookup might easily double the size of the editor Besides, the hex-do has another advantage: you can easily use non-western tuning, make "phat" basslines with detuning, etc... Well, don't worry, the manual includes a pitch-to-hex conversion table. If you feel like making a better one, please do!
Questions? Suggestions? Post them here!
UPDATE May 31st, 3013 - Version 0.3 is released
Some neat new stuff, including the long awaited "light" version. For details, click here (http://ourl.ca/18442;msg=295366).
UPDATE April 16th, 2013 - Version 0.21 is released
Added TI83 support and fixed a critical bug which prevented one of the sound routines from exiting. TI83+ port will probably follow soon.
UPDATE April 15th, 2013 - Version 0.2 is released
Contains loads of new stuff, for details check this post (http://ourl.ca/18442/345176)
Download link remains the same, see above.
-
Very impressive. My chiptune tracker only did 1 channel at the time.
Edit: It really is a pain to make music using a hex editor and converting notes by hand is not something a musician would like to do. I have experience with converting notes to hex values and hex values to frequencies which then had to be converted to hex. Is there a reason why you don't display the hex as musical notes? It could fit on the screen I guess.
Example:
(http://www.syntaxparty.org/beach/img/guide1tracker.gif)
-
Looks nice! How much space does the program take?
-
It's a super cool project, i wish i could test it out or help out in some way. Maybe we could look for optimizations to the hex editor source?
-
I wonder why are all the more advanced calc trackers are only on the 82? Does it just have better hardware for sound or something? O.O
That said this seems very cool. I really hope I can try this at one point. I have VirtualTI and the calc but I'm unsure if my ROMs runs it (my calc has 16.0).
Does anyone know how to send this to VirtualTI and WabbitEmu? It doesn't appear to support 82b files... (it just says transmission error on all 3 ROMs I tried) ???
-
Wow, that is pretty cool!
I wish I could try it out but I don't have a 82 :P
-
I think the readme says 16-19.0 are all fine, but 19.006 isn't supported.
-
Cool then, because I got a calc with 16.0 lol. I wonder if displaying both hex and the corresponding note (if applicable for the note in question) would be possible in the future for new musicians who are used to standard music creators?
-
If the source gets released, it will most certainly be possible ;) Perhaps there could be two versions, a lightweight hex-input version and a slightly larger note-based version?
-
Yeah true. Lightweight could be smaller and for older calc models, while the other would be for those who don't mind about file size. I still think that the note version should have hex too, though. Just a note selector that you can open if you hate manipulating this much hex by hand. We have to remember that it's a tracker, but some stuff for visual people wouldn't hurt (and would attract more users). :)
Another thing is that if this was done for the TI-84 Plus, it could possibly be used inside games, because the processor is 15 MHz instead of 6 and the calc has 480 KB of Flash memory. In fact, TI-Boy SE (Game Boy emulator) allows 3 sound channels at once.
By the way utz are the first two songs the only TI-82 songs on your SoundCloud account or were the others done with this program (and the other 82 program) as well?
-
Ti-boy is actuallly 4 channels, but the timing is not consistent unfortunately.
-
Thanks y'all for your responses! I'm glad some people here are interested :)
Looks nice! How much space does the program take?
At the moment, the editor+sound routine are about 1.4 KB, plus 10 K for user data. It will be extended to use all available RAM once the multiload/save feature is done.
It's a super cool project, i wish i could test it out or help out in some way. Maybe we could look for optimizations to the hex editor source?
I'll release the source code as soon as loading/saving and copy/paste functions are done. Also if somebody wants to port this to any of the newer models, you're more than welcome to do so.
What I really need at the moment is a working on-calc RLE+LZ77 packer/depacker. It could be quite slow, as long as it's small in size and efficient enough.
I wonder why are all the more advanced calc trackers are only on the 82? Does it just have better hardware for sound or something? O.O
I guess there's a simple reason for this - right now it seems I'm the only one developing 1-bit sound tools for the TI, and TI82 is the only model I own. TI82 isn't perfect, 86 would be the best of course ;)
That said this seems very cool. I really hope I can try this at one point. I have VirtualTI and the calc but I'm unsure if my ROMs runs it (my calc has 16.0).
Does anyone know how to send this to VirtualTI and WabbitEmu? It doesn't appear to support 82b files... (it just says transmission error on all 3 ROMs I tried) ???
VTI emulates the sound more or less correctly, but has a few problems with display timing. Also you need to switch off sound emulation before turning off VTI or it will go zombie. WabbitEmu's 82 display emulation on the other hand is totally broken as far as I can tell. both in recent and older builds. It'll also do the sound part right, though.
I think the readme says 16-19.0 are all fine, but 19.006 isn't supported.
Yeah I'll make a 19.006 version eventually, but it's not so high on my list of priorities. Personally, I think the 82CS sucks as a development machine - crap link port that wears out easily, and CrAsh 19.006 isn't exactly stable.
As far as the note/hex issue is concerned - this was one of the most difficult questions in relation to this project, and in the end I decided against it for a number of reasons:
- The conversion is rather arbitrary, so neither a linear nor a logarithmic function can be used for conversion. The only possibility would in fact be a lookup table for all 3,5 octaves. Also every 1-bit sound routine uses slightly different values, so in fact I'd need to make a table for every sound routine I implement.
- Atm the plan is to have at least 3-4 engines, with different functionality. Eg, there could be a 2-channel sound routine which uses the additional 2 channels for effect commands (timing, timbre, etc). Having a simple hex editor avoids the need to adapt the display driver to the sound routines each time.
- Since tuning is always a bit problematic with 1-bit routines, it is basically required to have a possibility for manually detuning the note data. So, if I were to make the input so it uses Note name + offset/detune parameter, I couldn't do the direct hex-to-RAM conversion anymore, which is the main secret ingredient for keeping the editor size down. Also, translating back the values is non-deterministic, since on higher octaves notes can be just 1 byte apart.
- Last but not least, if there were note names, how would you go about entering them? Either you type them in manually, which would be far less efficient than the current method. Or I tie notes to different keys, which would only be feasible if you turn the calculator sideways to edit. Plus, it would require a complex lookup considering the octave value must be taken into account.
That being said, someone has already suggested a useful feature that I'll probably try to implement somehow. Basically, it would translate the hex value which is currently highlighted by the cursor back into a note name, plus possible offset.
Concerning a port to later TI models, with or without added functionality, you are more than welcome to give it a try. As I said, I'll release the sources with one of the next updates. There are a couple of potential issues I see with it: The sound routine might need a major rewrite, unless it is somehow possible to slow down the cpu to the speed of a regular 82/83. Also reading song data directly from Flash will most likely be too slow. Well, I know zilch about the new models, so I'll leave it up to you to figure this out ;)
In-game use is not a good idea, because 1-bit routines block interrupts as well as any running keyhandlers, and take up 99% of CPU time, regardless of clock speed. (You could use it for title screens though. In this case these routines (http://irrlichtproject.de/downloads/ti1bit-0.2.zip) might be a better choice though.)
-
1 bit routines are always cpu intensive when you are going for multiple channels.
There really should be a calculator with hardware dedicated to sound. A TI84+ SE S?
-
Actually Keoni, one of my friends had an old graphing calc that was capable of producing beeps. The built in basic language even had support for it. It was pretty cool. :) His mom has been a math teacher forever, so that's where he got it from.
-
A HP calculator? Kraftwerk used one of those in their song "pocket calculator." (I don't know why I haven't covered that song yet with all of my sound peripherals XD)
-
Yeah for in-game use I meant like TI-Boy SE. However, seeing as some of your sound effects in Texas Beeping Massacre are slightly PC-88/Sega Genesis-esque, I am unsure how well it would sound.
As for note names, I thought about just an option to select notes through a drop-down if you press a certain key while over an hex value, and selecting a note would automatically paste in the appropriate hex code. Of course, however, this might be better if this is kept for a TI-83+ port that someone would make, since the 82 RAM is very limited. (The TI-83+ has less RAM, but it has 164 KB of archive so you got much more memory to work with)
Also VirtualTI doesn't support CrASH nor Ace. It says transmission error when the Warning: Backup screen appears on the calculator then selecting continue causes Error in Xmit. Sadly there is no existing emulator that can emulate the TI-82 properly it seems.
-
So i just tried this out with the new TilEm2 and it's super cool. The only thing is that the keys don't seem that responsive. I had fun just putting in random numbers and listening to what came out :)
-
@chickendude Wait... are you telling me that TilEm emulates sound now? Then why on earth am I still wasting my time on VTI???
I've fiddled quite a bit with the key handler, admittedly it's not perfect yet. The problem is, if I make the key delay any shorter, key repeat will kick in too quickly sometimes. Btw it feels a lot less quirky on real hardware.
@DJ_O: VTI does work for Crash and Ace, you just need to press "1" really quickly before the "User interaction required bla.." dialogue pops up. Sadly it's true that the emulation isn't accurate.
I somehow like your idea with the drop-down thingy. Eventually I'm gonna have to do something about that hex issue, considering all the requests ;)
-
You'll need to build it from the source at the SVN (svn co https://tilem.svn.sourceforge.net/svnroot/tilem tilem) with SDL installed. Then you can find an option to turn on sound in the Link menu :)
As for the keypresses, one thing you can do albeit a bit more complicated is after pressing a key have a timer that counts up until you release it. Once you reach a certain value you can start another timer which will let you scroll more quickly. So when you press the key there will be a short delay before the next repetition kicks in after which it'll scroll more quickly (like the TI OS menus/cursor). Or if you repeatedly press a key it'll scroll quickly, too. And another option for the note names might be to just place an octave number first then the note name, ie 1C# would be the lowest note and 4G# would be the highest. Maybe an apostrophe or something next to the note could indicate a sharp sign.
Anyway, it's a really cool program and especially if we can get it ported to some more popular calculators i think a lot of people could really have fun with it.
-
utz ah ok thanks for the info. Wish me luck because I tried that before, to no avail. X.x
And yeah I remember emulation not being accurate, although it was way worse with the TI-83+ and 89. (nowhere as bad as Flash Debugger, though). To this day, the most accurate emulator is PindurTI, but it lacks sound support and a GUI (so if you don't have the readme you don't know the keys). I wouldn't be surprised if TilEm topped it since it's still updated, though. Wabbit comes very close for newer calcs, except that contrast is messed up.
-
You'll need to build it from the source at the SVN (svn co https://tilem.svn.sourceforge.net/svnroot/tilem tilem) with SDL installed. Then you can find an option to turn on sound in the Link menu :)
Ah, that's awesome. Means I'll finally be able to switch development to linux. However, the sound support is rather problematic at the moment: The resulting pitch depends on the sampling rate and latency settings, which is clearly unacceptable.
As for the keypresses, one thing you can do albeit a bit more complicated is after pressing a key have a timer that counts up until you release it. Once you reach a certain value you can start another timer which will let you scroll more quickly. So when you press the key there will be a short delay before the next repetition kicks in after which it'll scroll more quickly (like the TI OS menus/cursor). Or if you repeatedly press a key it'll scroll quickly, too.
Hehe, that's actually more or less how I'm doing it. I've checked some more - the problem of unresponsive keys seems largely due to faulty emulation, (Tilem seems especially bad in that respect), on hardware the keyhandler runs pretty smoothly. It used to be faster, but beta-testers were complaining that it's too fast, so I slowed it down again ;) The only thing that makes it a bit sluggish is the process of scanning through 20+ keys. Have to see how I can optimize it further.
@DJ_O I have PindurTI too. And of course I can't remember where I put the godd*** readme. ;) Btw thanks a ton for the front page post!
-
No problem :). I actually planned to do it for a few months and there were even drafts written for TI-1-bit Pack, but unfortunately I lacked the time to do so. The release of Houston Tracker was a good occasion to post a news at the same time, though. :P
Also I noticed that in VirtualTI, when using Windows 7, the calc lags like crazy when you use the computer keyboard for keypresses rather than the calculator keypad. It made it particularly bad to play Mega Man, for example (it isn't due to sound because I had the same problem with sound disabled). Check this video for what I mean
-
Not intending to get off topic or anything, but Megaman always ran horrible on my TI-86. IIRC it was even slower on hardware than in VTI. It always bothered me that it ran so poorly.
-
I don't think I witnessed such lag when hitting keys, though. It wasn't super fast, but in VTI it literally freezes until 1 second after I release the key.
Hopefully a compiled build of TilEm2 with sound support comes out soon :P
-
Hi, would anybody with a ROM 19.006 care to test this experimental TI82CS build (http://irrlichtproject.de/downloads/HOUSTON196.82P)? Test on emulator first, to be sure.
The build contains the upcoming beta 0.2 with a ton of new features, which will be released very soon.
-
hey you guys! i see that 3 people downloaded the 82CS build, but nobody reports back here... c'mon xD
Anyway, version 0.2 is now officially released. As mentioned previously, it includes many new features, including:
- Copy/Cut and a few other things to make editing easier
- 2 new sound routines - TIM-FX (2 PFM channels, various fx), and Mark-2 (3 square wave channels) - sound demo (http://soundcloud.com/irrlicht-project/houston-tracker-for-ti-82-1)
- Can now change the song speed from within the song data
- Rudimentary "Live" features: can now pause or loop the current row during playback
- Simple Load/Save: can now preserve one additional song in memory
The download link remains the same - http://irrlichtproject.de/downloads/houston.zip (http://irrlichtproject.de/downloads/houston.zip)
Also HT now has it's own website (http://irrlichtproject.de/houston), with an extensive online manual.
I've decided not to release the source yet, because at the moment it's really messy and unoptimized. I'll definately release it with the next version though. However, if somebody wants to start with porting to 83+/84+ already, just pm me and I'll forward the source.
Now I have a couple of questions for all you seasoned TI programmers.
First of all, I was wondering if somebody had a table or something for converting TI82 ROM and CrASH calls to TI83. Basically, I need bcall/Ion equivalents for the following calls:
D_ZM_STR = _vputs? (Print zero-terminated string in small (menu) font)
D_LM_STR = ??? (Print length-indexed string in small font)
M_CHARPUT = _vputmap? (Print 1 character in small font)
CLEAR_DISP = _clrlcdf? (wipe LCD, but keep GRAPH_MEM)
CR_GRBCopy = _IonFastCopy? (copy GRAPH_MEM to LCD)
BACKUP_DISP = _savedisp? (copy GRAPH_MEM to APD_BUF)
Also, does anybody know of a shell for TI85/86 which offers an equivalent for CR_GRBCopy, resp. does anybody have a library for this?
Another thing that intrigues me is the compatibility of 82STATS/STATS.fr/76.fr machines. Are those fully compatible with 83, ie. will a program compiled for 83 automatically work on these machines?
And my last question concerns the 83+. If nobody else wants to do a port, I might try to do one after all. My main reason for not considering it so far was that I thought nobody would give a f*ck, but it seems the opposite is the case. So anyway, here's the question: What is the actual CPU speed of the 83+? I have some sources saying it's 6 MHz (which would be great, because then I don't need to adapt the sound routines), some saying it's 12.5 MHz, and some saying that you can switch between two modes. So what info is correct?
I know I could check all this on google, but honestly I don't want to spend another 3 months comparing and verifying dodgy docs for calcs that I don't own.
-
The 85/86 have a memory mapped LCD, you should just be able to LDIR it over. I actually looked up a lot of equates between the 82/83 not that long ago, i can't remember what i did with the information i gathered though. D_LM_STR sounds like _VPutSN. B = the number of characters to display. I also have it marked as _ClrLCDFull, but it should clear the LCD without erasing the gbuf. CR_GRBCopy is a CrASH routine? If so, then ionFastCopy is probably its equivalent. If it's an OS routine (much slower), you've got _GrBufCpy. _SaveDisp copies the LCD to a buffer starting at the address in HL, i'm not sure if that's what you want or not. If you just want to copy the gbuf to another area in memory, you can just ldir it. Altogether it's like 10 or 11 bytes.
The 83+ is 6MHz, as are the 83+SE/84+/SE. The 83+SE/84+/SE calcs also have a 15MHz mode, but you'll have to specifically declare it, by default they run at 6MHz.
The 82 Stats.fr is essentially an 83. I'm not exactly sure what the 76.fr is, but i believe it can also run 83 assembly programs without any issue.
EDIT: And i would release the source anyway, even if it's messy and unoptimized. Messy and unoptimized source is much better and more useful than no source at all ;) I'd love to help with an 83+ port, but i have no way of testing if it actually works or not. I don't have any fancy earphones or even a radio to test with :/
-
Yo, thanks a ton, chickendude. This should be enough to get me started. Looks like 83/83+ port won't be so hard to do after all.
The sources... yeah, you're right, I'd better get them out sooner than later. Just want to make sure that all the different ports will be compatible sound data wise. And believe me, it does need a bit of cleaning up, right now even I don't understand some parts of the code xD
-
If you assemble for ion it's likely you can do the 83/83+ port in one go. I don't know how much saferam you need, but i'm pretty sure the 83 and 83+ have more than 82. I know for a fact that the 83+ has more. If you need any help with either, i'd be glad to help (though my testing will be limited to using TilEm2) :)
-
And TI83 port is done already. It was even easier than I thought, everything worked right away. However, I have no means of testing this on real hardware, so be careful.
Also I found (and fixed) a bug which prevented one of the sound routines from exiting.
Download link stays the same, http://irrlichtproject.de/downloads/houston.zip (http://irrlichtproject.de/downloads/houston.zip)
You will need Ion 1.6U to run HT on TI83.
@chickendude: Luckily, I don't need saferam at all. I just use APD_BUF as a lazy way of backing up the screen. I'll probably do the TI83+ port tomorrow. Need to adapt some port values for that, which I'm too lazy to do right now ;)
-
Wow, that was quick! I really need to get some headphones that work with this... Can't wait to see the 83+ version :)
-
This project is awesome! I checked out the test songs and its really cool. Then i went and listened to SlayRadio for a few hours for that old school fix :).
-
And with some help from chickendude, the TI83+ port is done. Download as always at http://irrlichtproject.de/downloads/houston.zip (http://irrlichtproject.de/downloads/houston.zip)
HT83+ uses MirageOS, or DoorsCS (any newer shell might actually work). The song size was reduces to 1600 lines, due to the RAM limitations of the 83+. Also, the latest version fixes a small bug in the 83 port.
I'm assuming the 83+ version will also work with TI73. Anyway I have no means of testing the 83/83+ ports on hardware, so I'd appreciate some feedback/test reports on those.
-
I'm on it, utz. :)
It's an incompatible type for the 83+ port, though so I guess I'm not.
The only difference I can see is in the documentation (May not be different from other hardware models, like the 82...). The manual says that CLEAR stops playback, but VAR is the button that does it on the 83+.
I'm writing my own tuning table, I play piano by ear like a freak of nature and the tuning set you had annoyed me :P Not only was EVERY note a half step down, but many of them weren't tuned properly at all and I found out that it was easy to fix that. So, I'll post it here in a little while.
Releasing the source may allow some experts optimize your code :)
Also, if you change the hex interface so that each hex number corresponds to a certain note, (e.g. 01=C 02=C# it may make user interface easier.
I have some ideas for a fourth engine, more standardized. :)
I suggest it creates another prog for songs, so we can share
-
I think most of those are in the works. I dunno about changing the interface, but once the source is released there's nothing stopping us from doing that ourselves. Also, [Clear] worked for me. [Vars] might work, too, just because it's the same value as [Clear]. If [Vars] is stopping it, then other keys in that row ([Math], [Prgm], etc.) should stop the player, too.
Also, since the 82/83 version don't support external files, i think it'd make more sense to wait until the main engine is a little more developed/closer to its final state, that way you don't have to worry so much about keeping track 2 different engines or filling your code with conditional code à la Phoenix :P Anyway, i have a feeling the programs will be written for the 82 then ported to the 83/+ afterwards. But i agree, external files for songs would be nice. As it is, the songs are stored in the program itself, so if you want to share you'll just have to transfer the entire program over.
-
I think most of those are in the works. I dunno about changing the interface, but once the source is released there's nothing stopping us from doing that ourselves. Also, [Clear] worked for me. [Vars] might work, too, just because it's the same value as [Clear]. If [Vars] is stopping it, then other keys in that row ([Math], [Prgm], etc.) should stop the player, too.
Also, since the 82/83 version don't support external files, i think it'd make more sense to wait until the main engine is a little more developed/closer to its final state, that way you don't have to worry so much about keeping track 2 different engines or filling your code with conditional code à la Phoenix :P Anyway, i have a feeling the programs will be written for the 82 then ported to the 83/+ afterwards. But i agree, external files for songs would be nice. As it is, the songs are stored in the program itself, so if you want to share you'll just have to transfer the entire program over.
Actuall,y you're spot on. Any key in that row stops it for me, and a few other keys I believe.
yeah, chickendude I wrote a quick utility that lets me transfer the SONG as an appvar and then rewrite it in the program's buffer, just experimenting with the program.
There should be an app version..
Quick suggestion: Try to engine 3 capable of playing the squares at the same volume?
-
Do you think an app version'd be worth it? Once the source gets released, we can work on putting one out, i don't think it would need that much modification and it would open up a lot more RAM for songs.
-
Yup, during playback the port is masked with a 0, since xor a is faster than ld a,N. And timing is critical in these routines. That is also why i can't level out volumes in engine 3 - basically, it precalculates the counters for the next internal loop while it's playing the current one. So the only way to do it would be inserting nop-code, which would pretty much render the frequency range unusable. Even at an increase of 10 t-states, pitches below $80 are already pretty pointless. Besides, it's great to have multiple volume levels, makes simulating echos/reverb much easier.
Regarding simplifying the hex - for reasons I've explained in the OP, that's a definite no from my side. If somebody else wants to implement that, sure, why not.
As far as the pitch issue is concerned - yeah, that table works for engine 1 only, anyway. I thought my collegue had tuned it to exactly 440 Hz, but now I faintly remember that at some point we tried shifting it down a half-tone, as a work-around to massive detuning in the upper octaves.
As for an app/flash using version and/or storing the songs independantly, I very much agree that there should be such a thing. However, I won't be the one doing that since I don't have a clue about these newer hardware features. I'd be curious to see your utility though, dapianokid. And let me hear your ideas for a 4th engine, too - I have ideas for at least 10 more engines, and are actually working on the 4th one, but still I'm curious.
Btw today I realized that the 83+ version actually seems to work on the 84+ as well. Wow, I really know sh*t about these newer calcs.
-
utz, I'll be here to test and help out where I can.
Yeah, I understand why you won't simplify the hex.
If you don't implement it yourself, I'll write the stuff required to have songs as external variables. :)
My pitch table is almost done and it's really accurate.
The 4th engine... or engine X I guess :P :
Channel 0: Drum sounds of course, with a repeat toggle (for patterns!)
Channels 1-3: tones.
Channel 4: more information on pattern creation, like repeating X times or going back to the Xth sections.
-
@utz Yeah the thing is that the TI-84 Plus uses a 2.5x faster processor than the TI-82 and TI-83 Plus, so inevitably your songs will play this much faster, not twice slower as you initially thought. Of course there is the issue of lower RAM, though, especially on the TI-84 Plus Color model (which has 21 KB of RAM), so for those calcs the ability to play music directly from the Flash would be a good feature addition :)
The TI-83 Plus hardware is different from the TI-82, but there are many similarities, such as the CPU being Z80-based or literally a Z80. In ASM the difference is how ROM Calls are called and of course some memory addresses changed.
As for the TI-84 Plus, most ASM programs for the TI-83 Plus run fine on it, unless you use OS/ROM 2.53MP or higher, in which case there can be minor compatibility issues. The difference is that the calc also has crystal timers, more archive and a faster CPU.
The TI-84 Plus C Silver Edition is almost identical to the TI-84 Plus C Silver Edition, but it has a color screen and some RAM areas changed to different addresses as well.
Usually porting programs to newer calcs isn't super hard, compared to porting a TI-82 program to the TI-89, for example.
-
The TI-84 Plus C Silver Edition is almost identical to the TI-84 Plus C Silver Edition, ...
:P
The 83+SE/84+/SE need to be manually placed into 15MHz mode, so you don't need to worry about the speed change unless you want to use it. I don't know much about the math print OSes, but it seems like just turning off math print seems to work fine for most programs.
-
So today I did some optimizing, and managed to shave almost 150 bytes. My goal is to get the core routine down to <4K before I add new stuff, though it seems I might not quite make that target.
@dapianokid: that "pattern" idea of yours is actually pretty neat, though a bit tricky to implement. I wouldn't necessarily create a new engine for it, but I'm thinking about adding it to engine 2 at some point.
@DJ_O yeah the higher processor speed doesn't seem to create any problem so far. As chickendude pointed out, these calcs normally still run in 6 MHz mode.
Of course there is the issue of lower RAM, though, especially on the TI-84 Plus Color model (which has 21 KB of RAM),
OMG whatwheretheythinking. Anyway 21K means that the current 8xp version would still run on the 84+CSE.
But I take it the screen reso was changed as well? That'd be a major problem. I guess I'll leave the 84+CSE port to the experts ;)
-
well, the CSE has color, too, so you would have a problem. But, if you leave it the way it is and simply ass color, it woiuld display fine if it is font-based.
-
Version 0.3 is ready.
New stuff in this version:
- New load/save system with multiple save slots.
- A new drum sound
- A feature to mute channels seperatly. Affects only single row play mode, but also works for copy/paste.
- "Light" versions which don't eat up all the RAM, at the cost of a reduced maximum song length. Well, 1000 rows should still be enough to make some decent music.
- Various internal optimizations.
No internal compression yet. However I obtained a great Z80 LZ77 routine from one of the best ZX Spectrum coders in the world. It's proving a bit hard to adapt atm, but I'm working on it ;)
Download (http://irrlichtproject.de/downloads/houston.zip)
-
Actually, if I remember correctly, I *think* there might be some pre-existing LZ77 routines for the TIcalcs. You may want to do some poking around.
-
Oh nice, multiple save slots :D, and nice additions as well :)
-
Also, I somehow missed an 83+ version being completed. Good work guys! :) About a possible 73 version, although it is very similar to the 83+ they aren't binary compatible. I honestly wouldn't worry about it too muc though, as that platform never really caught on.
-
Very cool, nice to see more progress! I like the additions, especially saving/loading songs :) Also, the general z80 compression routines probably wouldn't be any different on the 82/3/+ simply because all they do is process data, no taking into account the screen size or anything specific to one platform. The 73 version probably isn't that urgent, either. I'd say most people who have a 73 (and use assembly games/programs on it) also have an 83/4+.
-
hey, glad y'all still with me ;)
@Art_of_camelot: I did quite a bit of research regarding a TI LZ compression routine. Seems there are various depackers, but no actual on-calc packers, at least none that are available as source.
@chickendude: Unfortunately, the routine I have is quite Spectrum-specific. It uses the FP stack (which is kinda hard to keep track of on TI, as far as I understand) and certain ROM functions that aren't available on TI. On the other hand it is very effective, achieving up to 70% compression. So it'd be great to use it. I'll post the routine here shortly if I absolutely can't wrap my head around it.
Regarding 73 version, I can probably build it from 83+ sources, so it would be very little work. Only thing I need to do is track down the address of the _clearlcdf routine which isn't listed in the available includes.
Also I'll get a TI85 next week, looking forward to porting to this one. If I succeed then I'm just two ports away from supporting all Z80 TI calcs ;)
-
Ah alright. For _clrLCDFull what's wrong with just writing your own routine?
bcall(_GrBufClr)
bcall(_GrBufCpy)
On Brandon W.'s site there's an include file:
http://www.brandonw.net/calcstuff/73dev/ti73.txt
It shows _ClrLCDFull as being at $44A7 :)
A port from the 85 to the 86 shouldn't be difficult, i actually think the 86 is backwards compatible with the 85, though i'm not sure if that also includes assembly programs or just BASIC. I've never actually used an 85 before and it's been years since i've touched an 86, though.
-
@utz: ok. I thought id seen the compression rotines around, but never looked much into them.
@chickendude:if anything the basic is compatible on the 85/86 (though im not even sure if it is). The asm is a bit different.
-
Yeah porting from 85 to 86 shouldn't be too hard. If I remember correctly it's possible to run Usgard and compatible 85 shells on the 86. Unfortunately though 86 is quite rare around here, and usually costs more than I'm willing to shell out atm.
Correcting my post from above, of course I meant "all Z80 TIs that have a link port". Would be hilarious to write a sound routine for 80/81 though. Theoretically it should work via radio interference method.
@chickendude ah, thanks! Somehow I must've missed that one. Or maybe some other routine was missing, I don't remember clearly. I do remember adding some custom stuff to ion.inc though.
-
Hmmm... The TI-80 isn't a z80 calc. :P
-
Some rare versions of the TI-80 (and IIRC, the 81 as well) have a link port, though.
-
Yeah but that's for ViewScreen so it's totally useless. They don't even support ASM.
-
Right, they don't officially support ASM. In practice, unsurprisingly, both the 81 and the 80 do, however :)
-
Oh that's pretty interesting. Do you have any links about it ?
Also I wonder what CPU is in the TI-80 (well 980 kHz isn't really fast but meh).
-
TI-81: http://www.ticalc.org/archives/files/fileinfo/425/42572.html (Unity shell)
TI-80: http://www.ticalc.org/archives/files/fileinfo/442/44237.html (emulator) , http://www.ticalc.org/archives/files/fileinfo/442/44236.html (documentation).
-
Thanks !
-
Barely 1MHz? Can you do anything useful with that thing?
-
Lol I don't think so. :P But it's a full fledged graphing calc so...
-
Hmmm... The TI-80 isn't a z80 calc. :P
whoops... well, no Houston Tracker for TI80, then. XD
980 KHz doesn't sound so bad... just about same speed as a PAL C64, actually. Depends on how efficient the m'code implementation is, really.
-
Managed to compile a 73 version (http://irrlichtproject.de/downloads/HOUSTON.73P). Would anybody care to test it? DJ maybe?
I'm quite surprised that the 73 actually has much more user RAM than the 83+. Whatwheretheythinking.
Still struggling with the 82CS version. Is it true that in OS 19.006 link port output values were changed to match the 83+ ones?
-
As long as it has samples included I can give it a go later today. :)
*Edit* Fixed a silly spelling error.
-
There are no samples included. Just enter "01 02 03 FF" in the first column, "40 40 40" in the second column, and "A0 A0 A0" in the third one. If you hear 3 different percussive sounds together with 2 (more or less) constant tones in all 3 engines, then all should be good.
-
Ok, so I'm upgrading the OS at the moment (the one on there currently is outdated) so I can test this thing. Should get back to you soon.
*edit* I got the OS updated, but TIconnect hates Mallard (the program required to run assembly programs) and I can't seem to get it to send with TILP either. :/ I have the tracker on the calc, but no way to execute it at the moment. :/
-
I think BrandonW was working to fix that TI-Connect issue a few days ago, but I am not sure what happened to it. IIRC the idea was to just make the shell an APP. As for TI-Connect, does it happen only with TI-Connect 4.0 or did it happen with 1.16.1 too?
As for the TI-80 I think drawing speed was about as fast as on the Casio PRIZM. It could still be used for some games, but they were as limited as the TI-81 and much slower. Also they looked like crap because the screen is 64x48 pixels large instead of 96x64.
-
After taking a break to take care of my personal life I'm now working on HT again. And more importantly, I've finally gotten around to publishing the source code (https://github.com/utz82/HoustonTracker).
I didn't clean up yet so the code is a bit of a mess. Also I'm a complete n00b in regards to git and version control in general, so please excuse me if not everything is set up correctly. Namely the formatting is screwed up right now, thanks to github forcing LF line endings. I'll fix this with the next commit.