> > 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.
This is exactly what I have meant.
> 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.
You're surely right.
I think the best solution is to put 12 most common functions to F1-F12.
And what about mouse? I bet for the following algo:
Turn mouse on when program reads that mouse port.
Turn mouse off when program doesn't read that port. This can be made
during reset automatically.
summary:
1. turn mouse off during reset
2. turn mouse on when mouse port is to be read
This *could possibly* help. The current state doesn't seem to be perfect.
> 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?
No, it is faster to ask you. ;)
> > 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.
That's why I do talk about it: optimisations are possible
> > 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
You can save it to a file. Clear.
But you can save it to "prn" file. What do you think you will get?
Think twice!
> 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 want DAC for Stefan's MOD player. It doesn't play in the current alpha.
I have three MOD players. The two others play without any problems,
Stefans' SamModPlay doesn't.
I think it is the right time to send my player to nvg. Anybody interested?
Is there a free space on nvg? I'm planning to put 20-30 SAD images.
> > 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 DOS it's easy :)
Well, you can close the port when no data is printed for 5 seconds. (or
3 seconds, or 1 second...)
> 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.
Especially since Dave has implemented envelopes, which can bev imported
into my SAAemu, regardless to the rest of the emulation library.
I mean that envelopes can be emulated with transparency, I mean the one
envelope emulation code can be shared acress several sound emulation
implementations.
> > 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?
AGP can accelerate RAM->video transfers.
PCI and VLB can accelerate video->video transfers only.
I hope you know this.
Several AGP cards work as PCI ones (incl. Voodoo and S3).
> 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.
So why are you interested in it? DX uses it automacically.
When the feature is not present, it is done by software.
Do you have any better algorithm?
----------------------------------------------------------------
Aley [eili] Keprt - student, programmer (multimedia soft. etc.)
phone: +420-68-538 70 35
e-mail: [EMAIL PROTECTED] *** http://get.to/aley
----------------------------------------------------------------
