Search options (Page 24 of 41)

Wouldn't it be possible to link Arduino C code against a pre-compiled library? Then such a library could be written in asm. That was actually what I was intending to do with the Z80 emulation.

Ah, excellent. I've been using my own (C++) lib for quick prototyping of XM converters since a while so I have no acute need for this, but mine is very badly designed so I can't publish it as a stand-alone library. So it's nice to have a clean and well-designed backup plan.

I'm surprised it's so slow, though. I mean Python is not exactly fast, but it shouldn't take that long. I took the liberty of running the script through cProfile and this is what I got:

         5450 function calls in 7.201 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.021    0.021    7.201    7.201 convert_octode.py:3(<module>)
        1    0.000    0.000    0.000    0.000 genericpath.py:55(getsize)
        1    7.138    7.138    7.138    7.138 xmlib.py:10(XM)
        4    0.000    0.000    0.000    0.000 xmlib.py:133(get_order)
        2    0.000    0.000    0.000    0.000 xmlib.py:140(get_pattern_length)
     1024    0.002    0.000    0.002    0.000 xmlib.py:148(get_note)
     1024    0.002    0.000    0.002    0.000 xmlib.py:153(get_instrument)
     1024    0.002    0.000    0.002    0.000 xmlib.py:158(get_volume)
     1040    0.002    0.000    0.002    0.000 xmlib.py:163(get_effect)
     1025    0.004    0.000    0.004    0.000 xmlib.py:168(get_parameter)
       15    0.000    0.000    0.000    0.000 xmlib.py:26(read_word)
        3    0.000    0.000    0.000    0.000 xmlib.py:29(read_dword)
        1    0.029    0.029    0.029    0.029 xmlib.py:32(load)
        1    0.000    0.000    7.138    7.138 xmlib.py:4(<module>)
        1    0.000    0.000    0.000    0.000 {len}
        2    0.000    0.000    0.000    0.000 {method 'append' of 'array.array' objects}
        1    0.000    0.000    0.000    0.000 {method 'close' of 'file' objects}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
        1    0.000    0.000    0.000    0.000 {method 'fromfile' of 'array.array' objects}
        1    0.000    0.000    0.000    0.000 {open}
        1    0.000    0.000    0.000    0.000 {posix.stat}
      276    0.001    0.000    0.001    0.000 {range}

I think the main bottleneck happens with setting up the arrays on constructing XM class object. I tried with XMs of varying complexity, there is almost no change in execution time. So the conversion functions aren't the problem, in any case. Not sure how that can be rectified. One could of course read the song parameters first and only set up the necessary amount of arrays afterwards, but I have a feeling that that doesn't tackle the problem at its root.

Hmm, this looks interesting, especially the last answer. I'm not a Python coder at all though.

Ok Shiru, you've convinced me of the benefits of a card that run standard beeper engines. Well, maybe Arduino is not such a good idea, after all - using a large Ardunio as the base of this might drive up the costs too much. I mean how much would people be willing to spend on this? 30€? Maybe 50 if it includes a joystick interface?

Either way I know very little about these things, so I'm afraid I can't be of much help.

Yo Zilog, good to read you on here! Your idea about using scalers has actually found it's way into this engine, though I think in a different form than you had envisioned it

Anyway, would love to see a new beeper engine from you, too! Squeeker has been very inspiring for me, and in terms of sound it's still one of my all-time favourites.

Belated Happy New Year from me, too! Back from my album recording session now and back on track for 1-bit world domination

Finally got around to listening to this properly. Awesome track, love that grinding fx at the end!

Neat!

"$db" is indeed a note value in hex notation, equal to 219 in decimal

I wonder what went wrong with those errors though. The line "#define db .byte" actually means the opposite in TASM, eg. "interpret '.byte' as 'db'". But as I said, back in the day when I wrote these I didn't have much of a clue about asm either. In any case, I promise to make a better version of ti1bit pack as soon as I can find the time, hopefully in January.

If you run into the "too many lines" problem, it might also suffice to put some dummy labels somewhere in the music data, eg.

   db $bla
   db $bla
   db $bla
dummyLabel1
   db $bla
   db $bla
   db $bla

Haven't tried this though. In any case, first thing for the new ti1bit pack will be to eliminate TASM and replace it with a modern assembler which doesn't bicker about stupid crap like that.

A note on speed: Speed conversion in ti1bit is not very accurate to begin with. But there are also other problems, some of which were discovered only recently. Namely 1) The TI-83 Parcus (the model you have) actually runs at around 7 MHz, despite the official specs claiming it runs at 6. 2) CPU speed on TI calcs fluctuates significantly depending on battery strength. On TI-83, it's not as bad as on some other calcs, but still normal to have +/- ½ MHz variation.

In theory it should just work by setting the loop point where you want it in 1tracker. I have no clue what I even meant by what's written in the ti1bit readme.

Ha, with a demo tune like this, it was totally worth it Looking forward to what you'll come up with. Please do post your stuff here, I'm curious.
And yeah, applying some eq is totally fine in the 1-bit world (well, in my opinion at least). Though lsengine is a pretty hopeless case. I've used it quite a bit for some time, but I never managed to get it to sound really good, neither on Spectrum nor on TI.

Hey, no problem at all. Using this crap package certainly isn't trivial and others might benefit from having these questions discussed. So no need to feel guilty.

Regarding the error, I'm a bit surprised by this one. I don't have any problem running TASM in DOSBox. But I just noticed that I'm appearantly using 3.1, not 3.2.
http://www.ticalc.org/archives/files/fi … /1504.html
Maybe using this ^ will solve the problem? Otherwise, I'd say 3.2 appears to NOT require DOS after all. So perhaps try to run in directly under Windows (though I doubt that would work under anything newer than XP)?

You're not giving up easily, are you? Well, with so much persistence, I don't have a choice but to help you

Ok, so first of all, you need the "other" TASM - not Borland, but Telemark. You can get it here:
http://www.ticalc.org/archives/files/fi … 25051.html
You'll probably need to run it in DOSbox, btw.
And devpac83 is here: http://www.ticalc.org/archives/files/fi … /3650.html
Just dump all the files in your working directory, where you have the asm files. "asm83.bat" goes into that folder as well.

Regarding step 5, just make sure the first two lines look something like this:

;#define TI82
#define TI83

Anything that has a ";" in front of it is considered a comment in assembly, and will be ignored by the assembler. If you just have the line "#define TI83" (without a ; in front of it), then that'd be correct. Don't worry about the "looping" part for now.

Also, don't worry about the "long song data corrupts TASM" part, unless you actually run into problems. If that happens, take this:

ptr1
loop1
    db $21
    db $2d
    db $1e
    db $2a
    db $20
    db $2c
    db $1c
    db $28
    db $2a
    db $1e
    db $26
    db $1a
    db $28
    db $1c
    db $25
    db $19
    db $2d
    db $2d
    db $2a
    db $2a
    db $2c
  bla bla bla...

and transform it into this:

   db $21, $2d, $1e, $2a, $20, $2c, $1c, $28, $2a, $1e, $26, $1a, $28, $1c, $25, $19
   db $2d, $2d, $2a, $2a, $2c, ...

Also yes, that rawp thing will be a bit easier to use. No need to fiddle with TASM, at least.