Chris Pile wrote:
>From: Simon Cooke (Exchange) <[EMAIL PROTECTED]>
>>>Would make Simcoupe very nice if it could refresh at the proper rate...
>>
>>I'm willing to go for 60Hz refresh, if the PC can make sure the emulation
>>runs a 50Hz frame's worth of processing in that time.
>
>Trouble is, things
-Original Message-
From: Simon Cooke (Exchange) <[EMAIL PROTECTED]>
To: 'sam-users@nvg.ntnu.no'
Date: 24 February 1999 21:27
Subject: SimCoupe
>>Would make Simcoupe very nice if it could refresh at the proper rate...
>
>I'm willing to go for 60Hz refresh, if the PC can make sure the emul
>Still on Simcoupe. Alan, you say the PIC's won't program correctly under
>Win32?
Well, yeah, because at that point they're hooked into the Windows Multimedia
timer system.
> Well, I don't know about NT but my Asteroids emulator uses a
>re-programmed PIC timer to force 60Hz refreshes when users
Hi all,
The screen blank register was always on my long list of possible
improvements, its not really that hard to implement as long as you don't
need the cpu speed change to be simualted.
My problem with the PC timers was not that they could not be reporgrammed,
I have done this, but it is not p
Hi All,
Regarding Simcoupe.
What I'd like to see implemented is the 'screen off' BIT on port 254.
Programs that turn the screen off to switch modes, or use screen area
as a workspace, look so messy when the screen *isn't* being turned off.
Flashes of crap look terrible!!
Wouldn't it be possibl
I've identified and fixed a bug in MNEMOcompress 2.00 which could cause a
possible crash during compression of some large files.
The original version was on Fred issue 68.
The new version (2.01) can be download from carou at:
http://carou.sel.cam.ac.uk/computers/mnemocompress.html
and has been
Hi All,
Looks like Simon has indeed found a bug in SimCoupe - one of many no
doubt. I'll really try to check and correct this in the next week. Chris's
problems with SimCoupe and defender may also be related to the frame
sync. mechanism used in the DOS version. On the UNIX version I just used
a SI
yeh, and then there's all the bugs in the DOS keyboard handler ... but i
won't go into all that
(example: in this order
(1) SHIFT
(2) 8
(3)
(4)
obviously wouldn't be an issue for a win32 port
)
dave
On Tue, 23 Feb 1999, Simon Cooke wrote:
> Hey Allan... here's some bugs for you in 0.78's so
> Hey Allan... here's some bugs for you in 0.78's source...
btw, what's the situation with the source for the DOS and Linux versions?
I've been converting the Linux X version over to Win32 as it's the closest
to a Win32 version(it runs, but I've still got the display code in pieces!).
My worry is
I think I may also know what's going wrong with the disk emulation;
you're not emulating index pulses, as far as I can see, nor are you
clearing the spin-up flag; ideally, the disk should take some time to
spin up, clear the spin up flag, and then perform the current command.
Si
__
Hey Allan... here's some bugs for you in 0.78's source...
Line 333; this should be:
hpen = LineNo-59;
// new code!
if (hpen > 192) hpen = 192;
Also, the status_reg stuff... you're only allowing one interrupt
at any time... how exactly does interrupt clearing work? Does each
interrupt last for 1
11 matches
Mail list logo
