Aley Keprt wrote: > Possibly. I don't have much time to spend with any alpha's. > Please send a beta, and we will see.
It's getting closer to becoming a beta - the version you have is certainly alpha as it lacks some important features that a beta would have (certainly disk/option saving!). The alpha was released early on request and does still give a taste of what it'll be like, even tho there are some bugs in it! > Well, there should be an option for these Alt+F etc. > Is it a problem to add some options to enable these shortcuts to the menu? The shortcuts work automagically if you use TranslateMessage() on everything in the message loop, even if you've not explicitly assigned shortcut keys in the menu resource. I'd taken it out, but it's now back in (optionally) along with the underlines in the menu, so everyone should be happy! I admit it might have confused some Windows users! > I don't use turbomon and I want Alt+F for emulator menu. Whad'ya mean you don't use TurboMON?! ;-) > You probably didn't see SimCoupe later than 0.78. Did you? > I changed the F-functionality a bit. Only more recently - from what I remember WinCoupe is based on a mixture of the 0.72 DOS and Unix sources. > e.g. I moved reset to F12, since this is a really strong function and it > should be "protected". > So I moved to the end of the keyboard :) > Also I moved NMI as well. (the same reason) I've stayed away from F12 as Windows NT has a built-in feature that halts programs if F12 is pressed when running under a debugger, which would be most inconvenient for my testing (tho I can always use an alternative key for the debug version). Having reset as a shifted key might also make it a bit safer than a plain key, tho I've yet to lose anything from hitting it accidentally. I was considering using some of the standard keys used by MAME and many other emulators: F9 Change frame skip on the fly F10 Toggle speed throttling F11 Toggle speed display Shift+F11 Toggle profiler display Any thoughts on using those? > btw. Your fast reset is the thing I everytime wanted. Thank you very much. :-) I do have an auto-boot option too, but it's not working well enough yet to put on the menu. One of the Mnemodemos enables a border effect (for debugging?) if F9 is held down, so I'd like to find a way reliably boots the disk but without holding it down for too long. > Or reversed. (right for menu, left for sam) But right-Alt is used for SAM Edit! > > You might then appreciate how much time and effort I've put > > into it so far. > > What? I won't go into this. > oooooo Looks like I might have taken your comment the wrong way! It can sometimes be hard to tell, but I'll have to be more careful - sorry! > takes too much programmers time, and gives too little benefits > (especially when we have your nice code) > :))) LOL! :-) > The question is what you do when a program uses double buffering (i.e. > switching VMPR at 50hz interrupt). Do you handle this anyway? The old method remembered the line number for the change, and redrew all lines from the current position up to that line number on the next frame, effectively doing a full redraw. Since the VMPR is being changed every frame it would mean a full screen redraw every frame. In that case there's no benefit from remembering dirty lines, so the emulation may run slow if the host machine isn't up to it. This is also true for anything that makes any palette/border/vmpr changes every frame, which is just about every SAM demo and most games! WinCoupe always redraws complete frames, but may skip drawing some frames to keep the emulation at full speed. The double-buffering doesn't make any difference really, and there certainly won't be any real visible different when frames are skipped (except it not being as smooth, which it can't be anyway if frames are skipped). > Although you all usually see my mails as "flamewars" etc., You sometimes have a way of wording things that come over as a bit provocative! > The thing which shlould be really optimised is floppy drive i/o. All disk images are read entirely into memory to give fast access and to work around not being able to selectively write to compressed files. Even the old uncached method might not be too bad under Windows as there's always going to be a disk cache to help out! The preliminary direct floppy access caches reads a track at a time (single sector reads seem a lot slower than DOS!), but does writes directly to the disk to avoid losses if the disk is ejected suddenly. It's still a bit flakey and will probably benefit from your expertise in that area! Si
