Aley Keprt wrote: > 0.78 is the latest version by Allan J.Skillman. There are several > advantages over 0.72. > Versions above 0.78 were compiled and distributed by me. There are several > new advantages. If you use 0.72 I consider this wrong.
I went from 0.72 as there were both DOS and Unix versions available, as the Unix version hadn't been updated to 0.78. I've since compared the source and can't see much that applies to what I've used. Most of the changes are in code that isn't used (DOS/Unix stuff, including UI) or has been re-written (floppy, sound, ...). > I thing people don't change frameskip and some other options so often. True, but I still find I do use it, and it's easier than going to the menu each time. If there are function keys free then there's no harm in assigning them to something. > As you wrote Sam Coupe programs usually redraw whole screen, your > WinCoupe redraw whole screen, so there is no reason of changing frameskip. That doesn't really make sense - frameskip isn't really anything with the full-screen redraw method. > Especially when there is no information about the fps in fullscreen, so > people can hardly see what happens. The new display is on-screen instead, so it's visible full-screen as well as windowed mode. > I found a bug: Joystick up and down are reversed. > Should be: 9=up, 8=down. Thanks, I'll check that - I guess the y-axis origin is opposite to what I expected. I've only ever played Manic Miner on my gamepad, which isn't something that really makes use of up and down! > I would be nice to see autoboot when I insert new disk (not after reset). It gets more complicated for disk insertions as it might require a reset to put the machine back in a state where the disk can be booted, and auto-resetting would be extremely dangerous! Why not just press the reset key followed by F9? The idea behind auto-boot was just to allow a method to start the emulator with a disk inserted and have it automatically boot. So it's a one-off boot done after the first reset only. > > But right-Alt is used for SAM Edit! > > (I'd like to see an option in WinCoupe to enable or disable right alt. I meant the EDIT key on the SAM - you must use that sometimes! Anyway, why would you possibly want right-Alt to be left alone? I can't see it's of any other use when WinCoupe is active anyway... am I missing something? I can understand the reasons for having 'Left-Alt as control' as optional, defaulting to disabled tho. > I have seen some software which uses two modes together (Sphera uses > mode 2 and mode 4 for lower part of the screen, Kapsa uses modes 3 & 4). > This worked well on SimCoupe. I hope it works in WinCoupe too. Of course it does! It's far more flexible than the original version in terms of updates - you can even do mode changes part way through a line, like some of the Mnemodemos use. Have you not actually tried these out on WinCoupe? > > You sometimes have a way of wording things that come over as a bit > > provocative! > > You're right. ;) It's also made particularly 'effective' by your strong opinions on some issues! > Also, I like to see direct writes into uncompressed images (to avoid > data loss when application/system crashes - can happen anytime in Windows :((( ). Uncompressed images are currently handled by transparently ZLIB, but it could still be done like that. > the usual one-sector writes are slow, and you never know how many > sectors of a particular tracks are to be written. True, but it's something that could be optimised by, say, caching writes within a single track until a different track is written to, then writing the track's worth of data out to the floppy. Not really thought about it much, but there are various ways to help speed it up. > And what about printer? Depends what you want to do with the data - I imagined it being more useful to write it to a file than out of the port, as you can do what you like with it then. Windows doesn't make it easy to provide the same low-level of port access as DOS, so it probably can't be as transparent as you might like (well, without resorting to methods very platform specific). I think the saving to a file Of course the SAM parallel port is also used for other devices, but there'll be an option to select the hardware you want on each port. > I though Allan already did this, since it is a really simple task. > Really simple task. It's easy if you just want to squirt it out of LPT1, with the read status faked to keep the caller happy. There's still a complication in that the Windows spooler won't see any data until LPTx is closed, so there will have to be something to guess when the job is considered done. It doesn't look as easy as you say... In a separate e-mail, Aley Keprt wrote: > I think the general structure of my emulator is better, but - > obviously - Dave's emulator have far better sound output. I'd say that was different rather than better - it's just an implementation difference in the way the modules are used. Dave's DLL is written as more of a utility module to produce sample data, but to leave the calling application to decide what to do with the data. It would be possible for his DLL to handle everything itself, giving the possibilities as yours - it could save it to a file or manage a DirectSound buffer to play it, but that's just not the way it's been done. The multiple algorithms you mentioned are good for cases where the output is an approximation, to give a choice for the approach to producing the data, but his method is accurate enough not to require any other methods. It does still provide options for the quality of data produced, which are about the closest equivalent to that. The current internal WinCoupe sound organisation would need to be changed to use your modules in addition to his, but that's not a problem - the current version is just tailored to Dave's module at the moment. If you were to share an API, the only additional function you'd need would be hints for the precise timing used for playing samples, which would be ignored for your sound code anyway. > I think the best solution is to take Dave's algorithms and > incorporate them into my SAAemu. Of course, you don't actually > need it, since your computer can simply play the wave data > created by existing Dave's emulator (SAAsound library). You'd have to discuss that with Dave, but I can't see a problem in having separate implementations with separate interfaces in the current version, just using a C++ wrappers to hide the implementation details of each. I don't see why either needs to be overhauled to make it like the other one. > I don't understand exactly what is wrong. You say that screen changes are > correct within 1 scanline. So why starfields are not visible? Do they use > some special timing inside a particular scanline? They are visible, but a couple of months ago I came across a strange case when they weren't - lemme explain... The sound implementation is done in such a way that no samples are generated until a change is made, and just before making the change it does a catch-up to generate all the samples up to that point. That way, if the sound chip isn't written to within a frame then no samples are generated until the end of the frame when it forced it to catch up and generate 1 frame's worth of data in a single chunk. If the chip is written to frequently (for samples etc.) then lots of little sample blocks are generated before making each change, and they're all buffered up ready to be written to the DirectSound buffer. I wanted the video generation to work in a similar way, so no data is generated until changes are made. This was fine for palette/border/vmpr changes since there is special code to do the same updating before actually writing the change to the internal registers, however there wasn't the equivalent code in the memory writing routines to 'see' changes made to the display (where the old code used to flag dirty lines). With the Entropy demo no changes are made to the palette/border/vmpr within the rest of the frame so the updating itsn't done until the frame interrupt. By that time the stars had been drawn and removed so they weren't visible when the screen was finally generated. This was fixed by forcing an update at the end of each scanline to make sure the line reflects the data state at that time. A better but more costly but accurate way of doing it is to do more specific checks on memory writes to see if the display data between the last update point and the current scan position is being made, and catch-up if so. It also means the main CPU module isn't really involved with updating the display, which 'feels' better in some way. You're not likely to notice any problems with the current method for now anyway. > Imagine the ray is on line 100 and I put on that line something. Then > the ray is on line 101 and I delete previous line (#100). What is shown > on that line? The appearance of line 100 remains unchanged until the beam reaches it during the following frame. Lines are part lines are generated for the lines the raster is currently on, so changes to other parts of the screen won't be seen until the beam reaches them, as is the case for the display on a real CRT. Doing it any other way would mean the displayed image would be wrong! > This is obvious. As far as I know all VLB/PCI/AGP videocards have > some acceleration. I played with it when I made some DirectX (2D) > games. I suppose the faster busses assist in transferring things faster between system memory and video memory, but do they provide additional support on top of that? The DirectX capabilities I'm interested in are DDFXCAPS_BLTSTRETCHX/Y, which show whether the driver/card natively supports blitting the image to the same size or larger; DDFXCAPS_BLTSTRETCHXN/YN are also useful for the image doubling that I use - all will be used automatically by DirectX if available. Si
