|
| |
|
Limon REU Wave Player V2 [2011] |
Website :
https://youtu.be/3ImB_j7J1uM
Credits :
Scrolltext and other text in this release : ()
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by chatGPZ on 13 October 2012
you rename the .wav file to .reu ? =P
created a proper entry for my little player too (REU Wave Player V1 (PoC)) incase you feel like updating your 1541u and still want to play those wav files =) |
User Comment
Submitted by DeeKay on 12 October 2012
Gpz: Are we talking about that wraparound bug now? Yeah, we came across that when we made BluREU. VICE ran it fine, but 1541u didn't. We got glitches during NUVIE replay, cause apparently 1541u's REU implementation respected stuff from Womo's REU test suite up to a certain degree!...
About that player: Insane quality! So how do I make my own .reu files to play with this? :-) |
User Comment
Submitted by Data on 14 February 2012
"lda $dc07
eor #$ff
sta $df06
... and you could even get rid of the eor #$ff by rearranging the data in reu memory accordingly."
Nice, that is 10 cycle routine. Shoveling 64KB blocks around in REU memory to throw that EOR away can take some 16-20s.
Switching REU pages can be done this way too:
LDA $DF04
ORA $DF05
For one oscilator there's no problem with speed. I've managed to write two oscillator routine using some optimization, but there's still 2 cycle deficit, so the playback at 44100 isn't as loud and good as in three oscillator REU player v2, but... yeach, compatible with REUs with paging mode only. |
User Comment
Submitted by chatGPZ on 8 February 2012
"The concept was to involve CIA to count down and switch the REU register by interrupt in right time."
that will obviously not work because the irq will take way too much cycles. what i do is simply:
lda $dc07
eor #$ff
sta $df06
... and you could even get rid of the eor #$ff by rearranging the data in reu memory accordingly.
edit: proof of concept
|
User Comment
Submitted by Data on 4 August 2011
"coincidence, like i said."
Where did You said this before?
The fix of this "bug" is just a philosophical concept of how REU should work beyond the 512K. You are fond of software banking, i'm a full addressing mode enthusiast. I think, that we agree on which of this method is faster. We only disagree on which of this method is "proper".
Regarding you routine. I though about using timers too, because i wanted to make this player compatible with all hardware - yup, i really did. The concept was to involve CIA to count down and switch the REU register by interrupt in right time. I didn't tried it yet, but there might be timing issues doing that nasty trick, that could affect the sound quality.
But the bottom line is, that it is a workaround, and having full address mode You wont be needing any of this, and still... You could do it the hard way. |
User Comment
Submitted by chatGPZ on 4 August 2011
"Accidentally this change was implemented when we had our "little" conversation on Ultimate Forum."
coincidence, like i said. it was only just comitted in january, because i actually forgot to do so. it was fixed a few months before when crossbow and/or deekay (i forgot) noticed me about the bug.
"i might consider that, when it will start using the Ultimate's REU features."
but it already does :)
"Words... they are so cheap this days... Don't be shy, show us ;-)"
i dont find playing wav files on a ridiculously extended c64 interesting enough to make a "tool" out of it really, i just hacked away an hour to prove it to myself. i can tell you what i did though: quickly disassembled your code, rewrote the player loop to play via the "new" 8bit method (oscillator restart) and then set up a cascaded cia timer to keep track of the current bank (one timer counts bytes played, the other will give you the twos complement of the current bank). eventually fixed timing accordingly by shuffling around stuff a bit. like you, i didnt bother to actually calculate proper 44.1khz timing and compensate for it (it is playing slightly too fast). that works for 44.1khz and the player is still a single naive loop. |
User Comment
Submitted by Data on 4 August 2011
"the behaviour in vice was changed (by me) before i even knew about this wav player."
Accidentally this change was implemented when we had our "little" conversation on Ultimate Forum.
"the name should be changed from "reu wave player" to "1541u wave player""
Thank You, i might consider that, when it will start using the Ultimate's REU features.
"i guess, it doesnt work on any reu at all"
Bold guess ;-)
"i have 44.1khz wav playing working _with_ proper wraparound btw"
Words... they are so cheap this days... Don't be shy, show us ;-) |
User Comment
Submitted by chatGPZ on 3 August 2011
the behaviour in vice was changed (by me) before i even knew about this wav player. the reason was that crossbow reported it as broken (rightfully so).
the name should be changed from "reu wave player" to "1541u wave player" i guess, it doesnt work on any reu at all =P
(i have 44.1khz wav playing working _with_ proper wraparound btw, its entire doable. without tinitussamples even =P) |
User Comment
Submitted by Data on 3 August 2011
This wave player gained a lot of good feedback because of spectacular sound quality and i want to thank You all for it.
It get some criticism for programming method, that I've used to achieve that quality too. Those critics like to say things like "behavior of vice, even though being intuitive is the false one" , so they changed the implementation of VICE.
Limon REU player cannot be run on VICE 2.3 anymore - use instead VICE 2.2 or older. |
User Comment
Submitted by chatGPZ on 2 June 2011
"There was some discussion about this bug/feature and people (including me by now) seem to agree that the behavior of vice, even though being intuitive is the false one."
and therefor it was fixed :) |
User Comment
Submitted by booker on 1 June 2011
User Comment
Submitted by Data on 18 January 2011
Enthusi, i have read Your method of bank swapping on moded REU some time ago. There is no CPU time to implement this in here. Only full address mode could make this samplerate possible.
In the case of moded REU behavior, i know that discussion about that was long and exhausting, but "people" are full of misinformation and irrational fear.
P.S. There are more bugs, but i need to investigate them more before i'll be eaten alive by those "people" for nothing ;-) |
User Comment
Submitted by enthusi on 17 January 2011
Data, you find some simple method to avoid the wrapping of REUs here: TAP Writer V0.2 > 512 KB
There was some discussion about this bug/feature and people (including me by now) seem to agree that the behavior of vice, even though being intuitive is the false one. |
User Comment
Submitted by MagerValp on 15 January 2011
User Comment
Submitted by Data on 15 January 2011
| 1750XL by CMD is supported up to 512KB. |
User Comment
Submitted by Conrad on 15 January 2011
| Nice one! One thing though... why not simply just add the player program here on CSDB and leave out the example tune?... I mean the example IS what's making the .zip/.7z too big to upload on here. As long as you've given us the specs on what type of file to rename as .reu (i.e. an uncompressed wave file) then we can choose our own song for the test. Not trying to pull your leg, but your own download links don't seem to work at all. |
User Comment
Submitted by MagerValp on 15 January 2011
Download link just leads to a bunch of ads and a 420 error.
I take it this doesn't work with 2 MB samples on CMD 1750XL?
|
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Info on other sites | |
|
| Support CSDb | |
|
 |  |
|
