Roger: I've never had an external RAM module and have never written a
program that requires the storage so I'm not talking from firsthand
experience. If you've tried it and encountered problems then I
probably can't help.

Simon: cool, sounds good. So it's just another clue (albeit quite an
authoritative one, with DirectSound at least) as to correct timing
rather than an absolute authority? Or maybe that's stating things too
vaguely and a better description would be analogous to a clock
multiplier sort of setup? The 2048/44100 comes in and you're saying
'so I'll push another frame at what I think is however-many hundredths
of a second from now, another at about 1/50th of a second after that
then wait for the next pulse'?

Sorry for the extended off-topic questions — I'm working on some brand
new emulation stuff myself, on and off, so I'm quite interested at the
minute.

On Tue, Oct 25, 2011 at 2:47 PM, Roger Jowett <rogerjow...@gmail.com> wrote:
> in the bottome 32k yes where the rom&speccy screen$ are
> but can the emulator explosion program be modified to do it? it
> already sdetects teh external ram
>
> On 25 October 2011 14:02, Simon Owen <simon.o...@simcoupe.org> wrote:
>> Yes, you could certainly fill the top 32K with faster external RAM.  Though 
>> using Spectrum-compatible mode 1 does add extra contention stripes, so 
>> you'll still get an extra hit on accesses in the bottom 32K.
>>
>> The current SDL version of SimCoupe uses 2048 samples, so it must have been 
>> what I found as the best behaving too!  Though I've always found SDL sound 
>> more awkward to work with as it requests extra data as needed, rather than 
>> providing a method to check the level and add more.  I'm expecting to use a 
>> mix of time stamps and buffer requests to trigger the next frame at the 
>> right point, which should solve the 22-syncs issue you mention.  It's a lot 
>> easier with DirectSound as you have tighter control over the play+write 
>> cursors, so you automatically get sub-frame accuracy (or you certainly used 
>> to – I've not checked with Vista or later).
>>
>> I have an occasionally worked on source branch that's moving towards doing 
>> that, though there are a number of related complications to untangle first.  
>> One day...
>>
>> Si
>>
>>
>> On 25 Oct 2011, at 13:18, Thomas Harte wrote:
>>
>>> I think I'm right to say that external RAM can be paged into the top
>>> 32kb of address space. And it's presumably uncontended? So you could
>>> page some in and run a 48 emulator but everything would run at quite
>>> the wrong speed.
>>>
>>> Simon: I've always found 2048 samples to be the sort of level where
>>> most operating systems start playing nice with audio output; assuming
>>> 44100Hz output, wouldn't synchronising to that limit you to only about
>>> 22 synchronisation points a second? So frames would end up bunched
>>> together?
>>>
>>> Not really on topic, I admit, and the evidence that you know what
>>> you're doing is plentiful. I'm just curious.
>>>
>>> On Tue, Oct 25, 2011 at 12:38 PM, Roger Jowett <rogerjow...@gmail.com> 
>>> wrote:
>>>> key repeats?
>>>>
>>>> is it impossible to run 48 emulator snapshots in external ram?
>>>>
>>>> On 24 October 2011 14:35, Simon Owen <simon.o...@simcoupe.org> wrote:
>>>>> Hi Ian,
>>>>>
>>>>> I'm hoping fixed running rates will come 'for free' as part of the switch 
>>>>> to audio-based synchronisation (rather than the current timer method).
>>>>>
>>>>> In the meantime, if you don't actually need the key repeats, try this 
>>>>> patched ROM to disable them:  http://dl.dropbox.com/u/2553707/norepeat.zip
>>>>>
>>>>> Extract it somewhere, then select it from Tools -> Options -> System 
>>>>> (tab) -> ROM image.  Reset the emulated machine to activate it.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Si
>>>>>
>>>>>
>>>>> On 23 Oct 2011, at 10:33, Ian Spencer wrote:
>>>>>
>>>>>> Hi Si,
>>>>>>
>>>>>> I'm sure you have been asked this hundreds of times before so I'll 
>>>>>> apologise before I start but I've always used SIMCOUPE synchronised to 
>>>>>> 50Hz with most programs and with others unsynchronised where the speed 
>>>>>> was useful (especially with the program which I have used for years to 
>>>>>> handle my bank accounts) and set the keyboard repeat rate to prevent 
>>>>>> multiple key presses being produced. But the modern 3Ghz 4CPU machines I 
>>>>>> now have are just so fast it's impossible to set the repeat rate low 
>>>>>> enough. They are just too fast and as many programs are much more usable 
>>>>>> when the speed is 200 -  500% above the standard it would be really 
>>>>>> fantastic if this was in some way selectable even if at this speed the 
>>>>>> instruction timings weren't very accurately scaled.
>>>>>>
>>>>>> Best wishes,
>>>>>> Ian Spencer
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>

Reply via email to