| ensoniq DOC swap bug discussion [message #378939] |
Sun, 23 December 2018 21:18  |
|
|
Originally posted by: fatdogprojects
hello everyone!
with Ninjaforce's latest NoiseTrackerPro demo, the IIGS has never been closer to perfect mod playback. It's really incredible work by them, with 90% of effects supported, straight ensoniq playback (can run full speed at 1 mhz cpu speed), and uploader/conversion tool that does a ton of tricks to get ensoniq friendly samples from 30 year old amiga mods, support for the 4soniq card, 15 channels, 255 samples, the list goes on and on. it's so cool :) it brought me here looking for more info. thank you ninjaforce!
So the Ensoniq chip in the IIGS has a notorious hardware implementation anomaly that has been discussed a lot in the past. Nevermind the fact that the GS ensoniq chip was the only version of it that had 64k instead of 128k that's not the issue (64k is a good chunk hehe). it is in the way it handles terminating loops and samples in memory by forcing a block of zeroes into the end of the final memory block
this has plagued music enthusiasts and developers forever by creating a crackling or static effect on so many sound effects. the anomaly manifests itself especially in music and makes some things un-listenable
i believe that there is a good work around this that could result in perfect playback of looped samples at a cost of ensoniq memory banks but only in the very specific situations where the disruptions happen.
unfortunately i have never even coded hello world so i'm of no help to coding this. i would like to throw my thoughts out there to see if anyone would like to run with it!
Jesse Blue of Ninjaforce has provided the source to both the NTP player and mod conversion tool at their website: http://www.ninjaforce.com/html/products_ninjatrackerplus.php
i will be experimenting with sample recordings to see if my theories hold up anyway!
so basically, as explained on the previous link (so much great info on it), ensoniq banks are locked in specific sizes, and there are no in-betweens. if you have a 33k sound sample, you are using the entire 64k of DOC memory.
the smallest possible bank is 256 byte. we will focus on that size from here on out since no matter what size the sample or loop, it will end on a 256 byte (32 block) page. this final page does not have to be full, but from what I understand the SoundManager will add a block of zeroes if it cannot find one by the end of the page
this is where the bug manifests. if you have sound data in that final 256 bytes, and it travels into the 32nd block, the chip is going to both 1. clip 8 samples and 2. increase the speed / frequency of loop playback by 1/32. my theory is that the final block of that 256 byte is never physically looped anyway. that only 31/32 blocks are played by the ensoniq. i do not have proof but when trying samples tuned for a 248 byte window i do not encounter static or clipping, and the bass seems to have the right amount of rumble
so if this is the case, then we can work around it by forcing LOOPS of specific sizes into using the next empty ensoniq bank. so we have 8 blocks that are reserved at the end of every page in a sample and loop (afaik).
knowing this, we can avoid using data in those reserved spaces. our loop that begins at sample 0 and ends at 256 has 8 bytes that would be replaced. if we add 8 bytes of silence to the end, and redefine our new loop end as 264, should we be close?
from what i can tell the ensoniq should play the 32 blocks, proceed to the next page, see zeroes immediately, and loop the 32 blocks while keeping the following bank completely empty. i am probably wrong
our reserved (illegal) ranges for loop sizes are 249-256, 505-512, 1017-1024, 2041-2048, 4089-4096, 8185-8192, 16387-16384, and 32761-32768. any data in those spaces will be overwritten by zeroes, and not played by the ensoniq
all other loop sizes should play without issue according to the logic.
and since C notes are the closest to a natural 256 X frequency I'd imagine they dominate the amount of samples out there. loops tuned to C are the most likely offenders
does this sound like it might work to anybody?
Happy holidays everyone, this is my first time visiting this place but I've been lurking in the AppleII underworld for many many years :D
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #378990 is a reply to message #378939] |
Mon, 24 December 2018 15:29  |
|
|
Originally posted by: fatdogprojects
incoming pseudo code made up by a monkey
def looplength (loopend - loopstart)
def size (original sample final byte)
if looplength =
249, 250, 251, 252, 253, 254, 255, 256,
505, 506, 507, 508, 509, 511, 512,
1017, 1018, 1019, 1020, 1021, 1022, 1023, 1024,
2041, 2042, 2043, 2044, 2045, 2046, 2047, 2048,
4089, 4090, 4091, 4092, 4093, 4094, 4095, 4096,
then append 8 zeroes to end of size
check that loop values are not changed
//This will double bank usage for the loop
//but not necesarily the sample
//the sample bank usage only doubles if it is ALSO
//one of the reserved values
//INVALID SIZED 16K SAMPLES WON'T FIT
if looplength =
16377, 16378, 16379, 16380, 16381, 16383, 16384
and total # of samples in module > 1
then abort
//if a 16k loop exists it already uses 32k if not 48k
//doubling that 16 will only fit in one specific case
//NOPE TO INVALID 32K SAMPLES
if looplength =
32761, 32762, 32763, 32764, 32765, 32766, 32767, 32768
then abort
//it will not fit
//the only way a normal 32k loop could fit is to trim or downsample
//99% of the time anyway
//automated downsampling and trimming is something worth thinking about
//though
//INVALID SIZED SAMPLES WITHOUT LOOPS (STRAIGHT SAMPLES)
if size =
249, 250, 251, 252, 253, 254, 255, 256,
505, 506, 507, 508, 509, 511, 512,
1017, 1018, 1019, 1020, 1021, 1022, 1023, 1024,
2041, 2042, 2043, 2044, 2045, 2046, 2047, 2048,
4089, 4090, 4091, 4092, 4093, 4094, 4095, 4096,
16377, 16378, 16379, 16380, 16381, 16383, 16384
and not looped sample
then overwrite the 8 final bytes with zeroes
then amplify sample #
(looplength - 09) -99%
(looplength - 10) -75%
(looplength - 11) -50%
(looplength - 12) -25%
//this will ensure that the non-looped invalid-sized sample maintains its
//bank usage on the ensoniq
//and also that the overwritten bytes do not introduce pops and cracks
//by fading the previous 4 samples (bytes) to 1% loudness
//gimme the trim and fade fam
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379051 is a reply to message #378939] |
Tue, 25 December 2018 20:18 |
|
|
Originally posted by: fatdogprojects
Pulled from https://www.vogons.org/viewtopic.php?f=46&t=46546
Re: amiga protracker instruments
Postby Jepael ยป 2016-2-03 @ 12:10
As others have said, they are just mono PCM samples in 8-bit signed format, length up to 128k (minus two bytes, as maximum is 65535 words).
What makes them "instruments" is the fact that you can specify a sample volume, sample loop points and note pitch fine tune values (in addition to a sample name).
IIRC, the "funny" base sampling rate for a 261.6 Hz C-2 note (actually C-4 on a piano) comes from some programming examples, where a 32-sample sine wave was played at 261.6 Hz, and this note required the sound hardware period value to be set to nearest integer value of 428, and 3579545 (sound chip clock for NTSC Amiga) divided by period value 428 is 8363.4 Hz. Those programming example
values for notes were just used as is in mod players.
Drum samples were usually played with higher notes than C-2, maybe at note A-3, because it was the highest standard note the DMA hardware could play back without skipping samples.I think by using finetune to speed up a bit it's still possible to play samples a bit faster without
skipping, maybe up to A-3 with finetune +3.
-------
perhaps a formula could be devised from these base values that allows us to:
1. resample existing amiga samples to a specific target size that fits within DOC properly
2a. find the correct value to "fine tune" the sample in our module to maintain pitch
or
2b. determine how many notes we need to adjust (transpose) to get closer to the original pitch
something simple like
sample size: 1118 bytes
target size: 1016 bytes
(sample size / target size) * 8272 = optimal frequency for GS
this gives us a lower frequency to downsample to
in this case 7517 Hz
if we downsample our 1118 byte file @ 8272 Hz to 7517 Hz,
we get a 1016 byte waveform
it can fit into a 1024 bank with exactly 8 bytes to spare
but
we have lost some sound resolution
we have increased our pitch by shortening the wavelength
the new waveform will not sound good in the module
we need to modify our pitch, or change the notes we play
i have not read up on the fine tune setting for module players yet, but hopefully by knowing the % we have increased or decreased the file, we can find a correct value here that maintains our pitch
if not, perhaps one could determine precisely how many "notes" you are away from the original frequency, and transpose the existing notes using that sample accordingly
side note:
if we do this to all of our samples, they will all be different sample rates. that can't be good but maybe it is not of consequence? perhaps we only need to do this for offending loopsizes. maybe for squeezing larger samples one way or the other...
my next post will talk about downsampling in more of a general sense. if done properly it can reduce a 31k file to 8k or less, and 4k with manual editing
with some work one can get large 300K amiga modules to fit into our little 64K banks
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379053 is a reply to message #378939] |
Tue, 25 December 2018 21:40 |
|
|
Originally posted by: fatdogprojects
ehh the new frequencies are going to need to be slotted into 12ths for the notes to work, but still doable i think
PERHAPS instead of targeting half, or an exact size,
we could target the nearest "# of twelfths away" that also comes closest to filling up the next lowest ensoniq bank
then we could have the proper note transposition number
----------
anyways, huge resampling saving are absolutely doable currently if the sample rate is HALVED and we drop a full 12 notes (octave)
if a 24000 byte sample at 8272 Hz is downsampled in half to 4136 Hz
it is now 12000 bytes and plays exactly 1 octave (12 notes) higher
we can find and replace all notes (using that sample) -1 octave
warning - if any notes are currently using the 4th octave, they cannot be replaced without dropping to the 3rd (which is technically supported in NTP)
instead of using 32K our sample uses 16K
- we lose alot of quality, think AM radio (FM at absolute best)
+ we do not lose pitch
if we do this to all of our large instruments, we can save ALOT of space at a very big quality trade off
by manually half-sampling, cropping, trimming, and deleting little used instruments, i managed to squeeze a 431k mod into that 64K. it didn't sound horrible either! just needs a little more work
i will be uploading a couple .2mg disks with some converted tunes soon if anyone is interested? you can fit 25+ songs on an 800k image. it might be the word DEMO that tips me off... but NTP only works from a 3.5" drive right now, and you have to reboot to play another song once you have one playing.
Ninjaforce has a demo disk at their site
http://www.ninjaforce.com/html/products.html#NinjaTrackerPlu s
boot from your GS or emulator, or open the "MENU" file from GSOS
if you want to add music, use the convert tool at their site
unzip the converted file
get that .ntp file to a 3.5" NTP Demo disk with CiderPress
put it in the DemoStuff\ directory on the disk
edit the DemoStuff\menu.txt file on that disk. (you can do this from CiderPress)
you need to manually make a new entry or edit an existing one
copy/paste an entire entry (up to the *) to add a new song
change the "name" and the "filename" in your new entry (if your filename does not match you will crash the program)
make sure there is a single blank line at the top of the menu.txt (or menu will not work)
save menu.txt
load up that MENU program (boot to disk or from GSOS)
there's still new music released just about daily if you look around the net. people still make music in 4 channel old style mod format too, it's crazy. i didn't realize that til NinjatrackerPlus tingled a bug i forgot i had
my next post will have some more detailed notes on how to make extreme cuts to large instrument files the really tough way. OpenMPT or another combined MOD/Sample editor with waveform manipulation tools will be required. OpenMPT is free. it does all the stuff we need plus a little extra. i believe NTP was rewritten using OpenMPT standard recently.
Merry Xmas everyone!
hopefully my notes help anyone interested in GS music development :)
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379082 is a reply to message #378939] |
Wed, 26 December 2018 21:24 |
|
|
Originally posted by: fatdogprojects
Ohhh kay I'm making some progress. I think I've found an optimal solution. We downsample fractionally, then tweak our frequencies with the fine tune setting. It seems to work.
Good
+ 96.4% to 99.99% fidelity maintained
+ pitch is very very close to original if not identical with finetune
+ filesizes never increase
Bad
- We have different sample rates for affected samples and loops (might be negligible)
- The frequency differential might throw off pitch more than I've tested thusfar
So I have to learn some php if I want to get my theory some action, but until then here is some more monkey code. hopefully it makes some sense without any syntax whatsoever. but basically the idea is we find our ratio to downsample to intelligently, then downsample, and adjust our loop points if needed. there is a check at the end in case we add further bad lengths with our fix. this should only spit out an Ensoniq friendly sample at a different frequency, or skip the file if it is ok
get file
get LoopEnd
trim after LoopEnd
/* this is necessary */
get SampleRate
if SampleRate >8272 or <8272 goto end
get (LoopEnd - LoopStart), set as LoopLength
get filesize, set as SampleLength
get LoopLength
get SampleLength
def bad 0249, 0250, 0251, 0252, 0253, 0254, 0255, 0256,
0505, 0506, 0507, 0508, 0509, 0510, 0511, 0512,
1017, 1018, 1019, 1020, 1021, 1022, 1023, 1024,
2041, 2042, 2043, 2044, 2045, 2046, 2047, 2048,
4089, 4090, 4091, 4092, 4093, 4094, 4095, 4096,
8185, 8186, 8187, 8188, 8189, 8190, 8191, 8192,
16377, 16378, 16379, 16380, 16381, 16382, 16383, 16384,
32761, 32762, 32763, 32764, 32765, 32766, 32767, 32768,
or > 65536
def good 0001-0248, 0257-0504, 0513-1016, 1025-2040, 2049-4088,
4097-8184, 8193-16376, 16385-32762, 32769-65536
if LoopLength = good then goto II
if LoopLength = bad and < 0257 then TargetSize = 0248
if LoopLength = bad and > 0504 but < 0513 then TargetSize = 0504
if LoopLength = bad and > 1016 but < 1025 then TargetSize = 1016
if LoopLength = bad and > 2040 but < 2049 then TargetSize = 2040
if LoopLength = bad and > 4088 but < 4097 then TargetSize = 4088
if LoopLength = bad and > 8184 but < 8193 then TargetSize = 8184
if LoopLength = bad and > 16376 but < 16385 then TargetSize = 16376
if LoopLength = bad and > 16384 then goto end
get ((TargetSize/LoopLength) * 8272), set as FixedLoopRate
get ((TargetSize/LoopLength) * LoopLength), set as FixedLoopLength
downsample to FixedLoopRate
get filesize, set as FixedSampleLength
get FixedSampleLength, set as LoopEnd in file
get (FixedSampleLength - FixedLoopLength), set as LoopStart in file
save file
get SampleLength
if Sample Length = good then goto 66
if SampleLength = bad and < 0257 then TargetSize = 0248
if SampleLength = bad and > 0504 but < 0513 then TargetSize = 0504
if SampleLength = bad and > 1016 but < 1025 then TargetSize = 1016
if SampleLength = bad and > 2040 but < 2049 then TargetSize = 2040
if SampleLength = bad and > 4088 but < 4097 then TargetSize = 4088
if SampleLength = bad and > 8184 but < 8193 then TargetSize = 8184
if SampleLength = bad and > 16376 but < 16385 then TargetSize = 16376
def GetFixedSampleRate ((TargetSize/SampleLength) * 8272)
run GetFixedSampleRate, set as FixedSampleRate
downsample to FixedSampleRate
save file
get LoopLength
if bad goto 14
/*this is a double check*/
get next file
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379083 is a reply to message #378939] |
Wed, 26 December 2018 21:38 |
|
|
Originally posted by: fatdogprojects
////MASTER LIST
bad new fine
size rate tune
bytes Hz
TO FIT 31/32 BLOCKS
0249 8239
0250 8206 -1
0251 8173 -1
0252 8141 -2
0253 8109 -3
0254 8077 -4
0255 8045 -5
0256 8014 -6
TO FIT 63/64 BLOCKS
0505 8252
0506 8236
0507 8220
0508 8204 -1
0509 8188 -1
0510 8171 -1
0511 8155 -1
0512 8140 -2
TO FIT 127/128 BLOCKS
1017 8263
1018 8255
1019 8247
1020 8239
1021 8231
1022 8223
1023 8215
1024 8207
no more fine tune needed after this point, frequencies are close enough to original and im getting lazy
after 4K, we can just choose one frequency to resample to for each bank size, as the resamples are within 64 bytes or so of the original size
we can also easily choose a smaller window to resample to if we want more of a buffer with that 0 block. if we want to calculate for 244 bytes we would just subtract four from our TargetLengths above and all should work (with slightly more fine tune needed)
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379084 is a reply to message #378939] |
Wed, 26 December 2018 21:58 |
|
|
Originally posted by: fatdogprojects
can someone recommend a less sophisticated older IIGS mod player that would handle Ensoniq DOC usage a little more crudely than soniqTracker or the NinjaTrackers?
I'd like to do some more experimentation and see if the documentation on this issue from back in 1989 is misguided. Where can i find some good info on how older players handled the DOC?
next thing up is to create a scaling method for non-problematic samples and loops. i think we can downsample everything to fit the next smallest block, with not as severe fidelity loss. I believe the magic number is 32 notes below us at 8272 Hz, so we definitely can transpose our notes to a range and know how far we've traveled
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379093 is a reply to message #379084] |
Thu, 27 December 2018 09:01 |
Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, December 27, 2018 at 3:59:00 AM UTC+1, fatdogp...@gmail.com wrote:
> can someone recommend a less sophisticated older IIGS mod player that would handle Ensoniq DOC usage a little more crudely than soniqTracker or the NinjaTrackers?
>
> I'd like to do some more experimentation and see if the documentation on this issue from back in 1989 is misguided. Where can i find some good info on how older players handled the DOC?
>
>
>
> next thing up is to create a scaling method for non-problematic samples and loops. i think we can downsample everything to fit the next smallest block, with not as severe fidelity loss. I believe the magic number is 32 notes below us at 8272 Hz, so we definitely can transpose our notes to a range and know how far we've traveled
Use Soundsmith from Huibert Aalbers. It loads instruments in the DOC RAM,
av
|
|
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379096 is a reply to message #379094] |
Thu, 27 December 2018 11:31 |
|
|
Originally posted by: fatdogprojects
hi antoine
thankyou for your recommendation, i will look into soundsmith. sorry for any confusion, I am very much a novice at this
1 block = 8 bytes
our DOC banks can only be 256/512/1024/2k/4k/8k/16k/32k, and no other size
a full block (00000000) lets the SoundManager know that the sample has ended
if SoundManager can not find (00000000) by the end of the bank, it will forcefully add it at the end, overwriting any data in the "final block"
this disrupts waveforms with data in the final block, since they are incomplete now.
256 / 8 = 32 blocks is our smallest bank size possible
say an amiga sample has 256 bytes of data
Ensoniq DOC only uses 248 of 256 of those bytes since one block now (00000000)
8 bytes of sound data is missing, breaking a waveform and loop
IMHO this is the fault of the SoundManager memory allocation rather than a hardware problem. i believe by avoiding having any data at all in the last block of a bank we can completely avoid the issue
i don't think patching SoundManager is ROM is something i'm quite ready for yet hehe. So i try this for now
|
|
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379102 is a reply to message #379096] |
Thu, 27 December 2018 12:06 |
Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, December 27, 2018 at 5:31:40 PM UTC+1, fatdogp...@gmail.com wrote:
> hi antoine
>
> thankyou for your recommendation, i will look into soundsmith. sorry for any confusion, I am very much a novice at this
>
> 1 block = 8 bytes
>
> our DOC banks can only be 256/512/1024/2k/4k/8k/16k/32k, and no other size
>
> a full block (00000000) lets the SoundManager know that the sample has ended
>
> if SoundManager can not find (00000000) by the end of the bank, it will forcefully add it at the end, overwriting any data in the "final block"
>
> this disrupts waveforms with data in the final block, since they are incomplete now.
>
> 256 / 8 = 32 blocks is our smallest bank size possible
> say an amiga sample has 256 bytes of data
> Ensoniq DOC only uses 248 of 256 of those bytes since one block now (00000000)
> 8 bytes of sound data is missing, breaking a waveform and loop
>
> IMHO this is the fault of the SoundManager memory allocation rather than a hardware problem. i believe by avoiding having any data at all in the last block of a bank we can completely avoid the issue
>
> i don't think patching SoundManager is ROM is something i'm quite ready for yet hehe. So i try this for now
Thanks for the clarification.
The Ensoniq requires 8 zeroes at the end of a sound to ensure the oscillator is stopped. That is because of the sound resolution which can play 1 sample every 8. By adding eight zeroes, you guarantee the oscillator to stop.
For more information:
- http://www.brutaldeluxe.fr/documentation/cortland/v3_04_Note sOnEnsoniqDOC.pdf
- http://www.brutaldeluxe.fr/documentation/cortland/v4_12_Soun dTools.pdf
- http://www.brutaldeluxe.fr/documentation/cortland/v4_13_Enso niqDOC.pdf (read last paragraph of page 8)
Antoine
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379103 is a reply to message #379102] |
Thu, 27 December 2018 12:11 |
Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
The SoundManager adds 64 zeroes if and only if a sound is not a multiple of 256. Hereafter is the code excerpt:
wave_mover sep #$30 ; 8 bits please
move_loop ;
lda [scratch],y ; get a byte
sta gdatreg ; write it to the sound glu
iny
bne move_loop ; move one page
rep #$20
inc scratch+1 ; bump source pointer
dec gcb_wave_count,x ; decrement wave page count
beq wave_done ;
dec page_count ; decr number pages to move
bne wave_mover
lda scratch ; set new wave start position
sta gcb_wave_pos,x
lda scratch+1
sta gcb_wave_pos+1,x
bra exit_wave_mover ; all done for this block
wave_done ;
lda page_count ; did we fill the DOC buffer?
dec A
beq @1
LONGA OFF
LONGI OFF
sep #$30
lda #$00 ; pad with 8 zeros (Antoine: not correct, it is 64 zeroes)
ldy #$40 ; need 64 zeroes
@2 sta gdatreg
dey
bne @2
LONGA OFF
@1
sep #$20
----
Antoine
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379104 is a reply to message #379103] |
Thu, 27 December 2018 12:33 |
|
|
Originally posted by: fatdogprojects
On Thursday, December 27, 2018 at 12:11:49 PM UTC-5, Antoine Vignau wrote:
> The SoundManager adds 64 zeroes if and only if a sound is not a multiple of 256. Hereafter is the code excerpt:
>
> wave_mover sep #$30 ; 8 bits please
>
> move_loop ;
> lda [scratch],y ; get a byte
> sta gdatreg ; write it to the sound glu
> iny
> bne move_loop ; move one page
> rep #$20
> inc scratch+1 ; bump source pointer
> dec gcb_wave_count,x ; decrement wave page count
> beq wave_done ;
>
> dec page_count ; decr number pages to move
> bne wave_mover
> lda scratch ; set new wave start position
> sta gcb_wave_pos,x
> lda scratch+1
> sta gcb_wave_pos+1,x
> bra exit_wave_mover ; all done for this block
>
> wave_done ;
> lda page_count ; did we fill the DOC buffer?
> dec A
> beq @1
>
> LONGA OFF
> LONGI OFF
>
> sep #$30
> lda #$00 ; pad with 8 zeros (Antoine: not correct, it is 64 zeroes)
> ldy #$40 ; need 64 zeroes
> @2 sta gdatreg
> dey
> bne @2
>
> LONGA OFF
>
> @1
> sep #$20
>
> ----
>
> Antoine
inredible, thank you so much antoine. i humbly apologize, i did not realize how much information i've completely skipped over. i will try to catch up to you guys and report back!
|
|
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379108 is a reply to message #379105] |
Thu, 27 December 2018 14:33 |
|
|
Originally posted by: fatdogprojects
On Thursday, December 27, 2018 at 12:52:27 PM UTC-5, Antoine Vignau wrote:
> Do not apologize, what you are doing is great! Keep up the good work,
> av
Alright! i'm going through all this incredibly valuable information, and it is raising so many questions. it's also making me feel like we are headed in the right direction, so there is that
i do not understand 99% of code that so far. really, only the commenting makes any sense to me and not at a high rate. the hardware diagrams are way over my head but can tell that what i'm looking for is there. my first thoughts at this point without understanding the full picture are:
1. 64 0's added for all samples not = x256? wow
2. does that hold true if 36 zeroes are added to end of 230 file to bring it to 256?
3. our target windows stay the same if i understand correctly, so if we resize _all_ samples to fit that, then add exactly 8 0's
4. HMMM! on the sound modes. perhaps a different choice of mode for different sized samples could help. very interesting and worth thinking about!
5. we need to run a zero filter on our samples (like rSounder), for all samples period
6. there could be an alternate way to fix very very small (under 64 bytes) loops
i'm going to keep reading this perfectly tailored bundle of information
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379329 is a reply to message #378939] |
Thu, 03 January 2019 16:50 |
Christopher G. Mason
Messages: 156
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 12/23/2018 9:18 PM, fatdogprojects@gmail.com wrote:
> hello everyone!
>
> with Ninjaforce's latest NoiseTrackerPro demo, the IIGS has never been closer to perfect mod playback. It's really incredible work by them, with 90% of effects supported, straight ensoniq playback (can run full speed at 1 mhz cpu speed), and uploader/conversion tool that does a ton of tricks to get ensoniq friendly samples from 30 year old amiga mods, support for the 4soniq card, 15 channels, 255 samples, the list goes on and on. it's so cool :) it brought me here looking for more info. thank you ninjaforce!
>
Just don't rely on IIgs emulators when testing. They don't emulate the
swap mode bug for obvious reasons. Plus, there are other inaccuracies
depending on the emulator.
> So the Ensoniq chip in the IIGS has a notorious hardware implementation anomaly that has been discussed a lot in the past. Nevermind the fact that the GS ensoniq chip was the only version of it that had 64k instead of 128k that's not the issue (64k is a good chunk hehe). it is in the way it handles terminating loops and samples in memory by forcing a block of zeroes into the end of the final memory block
>
The 5503 couldn't directly access all 128k of RAM anyway, Ensoniq used
the "BS/bank select" pin to access each 64k block in their keyboards.
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379339 is a reply to message #379329] |
Thu, 03 January 2019 18:38 |
|
|
Originally posted by: Anthony Adverse
On Friday, January 4, 2019 at 8:51:19 AM UTC+11, Christopher G. Mason wrote:
> On 12/23/2018 9:18 PM, fatdogprojects@gmail.com wrote:
>> hello everyone!
>>
>> with Ninjaforce's latest NoiseTrackerPro demo, the IIGS has never been closer to perfect mod playback. It's really incredible work by them, with 90% of effects supported, straight ensoniq playback (can run full speed at 1 mhz cpu speed), and uploader/conversion tool that does a ton of tricks to get ensoniq friendly samples from 30 year old amiga mods, support for the 4soniq card, 15 channels, 255 samples, the list goes on and on. it's so cool :) it brought me here looking for more info. thank you ninjaforce!
>>
>
> Just don't rely on IIgs emulators when testing. They don't emulate the
> swap mode bug for obvious reasons. Plus, there are other inaccuracies
> depending on the emulator.
>
>> So the Ensoniq chip in the IIGS has a notorious hardware implementation anomaly that has been discussed a lot in the past. Nevermind the fact that the GS ensoniq chip was the only version of it that had 64k instead of 128k that's not the issue (64k is a good chunk hehe). it is in the way it handles terminating loops and samples in memory by forcing a block of zeroes into the end of the final memory block
>>
>
> The 5503 couldn't directly access all 128k of RAM anyway, Ensoniq used
> the "BS/bank select" pin to access each 64k block in their keyboards.
That's one that always looked like a no brainer, why no one ever tried to expand that docram. You'd have to teach it the bank switching but other than that....
|
|
|
|
| Re: ensoniq DOC swap bug discussion [message #379464 is a reply to message #379339] |
Sun, 06 January 2019 16:58 |
Polymorph
Messages: 206
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, January 4, 2019 at 10:38:13 AM UTC+11, Anthony Adverse wrote:
> That's one that always looked like a no brainer, why no one ever tried to expand that docram. You'd have to teach it the bank switching but other than that....
I do remember seeing someone do exactly this a number of years ago - they hacked the extra 64Kb DOCRAM onto the motherboard and wired it up somehow.
Unfortunately, I do not remember who or even what site this was on when I read about it (just thought it was cool at the time).
Maybe someone else can remember the details of what I am talking about?
Cheers,
Mike
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
