RE: Original SAM design?
Allan Skillman wrote: I remember that one, there was a series in Crash back in 1988-89, which included early designs for the Sam. Unfortunately I had to throw out all my old copies of Crash on pain of death (or worse) a while back. Sounds rather familiar! Alyson refused to allow mine to come with us when we moved house - I can imagine it was something like that for you! Still, I did go through all of them first to pull out any good articles to keep, which did include the SAM stuff :-) Si
RE: Windows 2000 - the new spawn of satan?
Simon Cooke wrote: Win2k has better direct disk access support Maybe, but only _just_ from what I can see! ; you have to use the IOCTL's though. All they seem to have done is break up floppy.sys into flpydisk.sys and fdc.sys, and create some internal I/O control codes to communicate between them. It does mean a new floppy driver no longer includes any direct controller communication (and has added arbitration), but means that the rest (and the most part too) must still be done in the new driver. For a SAM-friendly driver it still seems to require flpydisk to be rebuilt (after some minor tweaking), which is something that could have been done under NT4 too! With a change in driver layout it just seems to have made things more complicated to support both W2K and NT4. I explicitly asked the Win2k NTFS team for it ... why? for SIMCoupe' of course :) Flpydisk.sys still has the same fixed format-detect tables for various floppy formats, and won't treat a low-density disk as anything other than 9 sectors per track :-/ Am I missing something? Perhaps you could enlighten me on how a W2K solution is now so much easier! How's that for forward planning? :-) It would have been much nicer to have something like a IOCTL_DISK_SET_DRIVE_GEOMETRY to allow overrides for particular formats, which is what I ended up writing a driver to do for a W2K _and_ NT4 solution. Or perhaps they could also have allowed sector access using CHS addressing in addition to the linear device-style access... Si
RE: Expansion Memory
Andrew Collier wrote: HMPR (251dec) bit 7 MCNTRL If this bit is set when the CPU addresses high memory, then the external signal XMEM goes low and the Coupe looks on its expansion connector for memory sections C and D (addresses 32768 to 65536) This isn't enough information. I'm pretty certain there are another two ports, one each to specify a page in sections C and D. But I've no idea what port addresses they're at. Port 0x80 is the external page for section C, and port 0x81 is for section D. As you said above bit 7 of HMPR has to be set for these to be visible, and the page in section D appears to cover ROM1 when paged in too. The other important things is that each extra MB added is present from the top of memory down. If you have the maximum 4MB then all external pages from 0 to 255 are available, but if you have 3MB then only 64-255 are valid (128-255 for 2MB and 192-255 for 1MB). Over to... Si? Well, over to the SimCoupe source - I don't have any external memory either! Si
RE: free: the complete spectrum rom disassembly
Ian Collier wrote: imc (who already has one, but all the pages are falling out) Heh, mine too :-) I still vividly remember how hard it was to get hold of that book in the first place too! Si
RE: So... where do i get it?
Edwin Blink wrote: or EDDAC Are the SAMdac and EDDAC both 8-bit stereo on the same ports? Will you also implement a COM port ? Would that be for a modem, or did you have something else in mind? I did have a bit of a play with the serial port stuff, which was enough to get it to talk to my modem on COM1, but not enough to add to the GUI. I managed to extract a few details from Simon Cooke's Termite source (is there a binary of that available?) to get that working, but I don't have any other docs to work with - can anyone help me with that? Si
RE: Anyone help here
David L wrote: It was pretty much a standard SAM format... although there was an unformated sector IIR Depends whether the game refuses to run if it can't find it - probably if it's the intended protection! An SDF image would preserve the original format and wouldn't require any code modifications to hack around it, etc. Anyone got it for sale? Si
RE: Anyone help here
Chris White wrote: But i have a proxy server that only send mail if high priority , will have to look @ setting on that end ah, you have our sympathy! At least you don't have something that tags a 50 line disclaimer to the message! ;-) Si
RE: So... where do i get it?
David L wrote: So, where can I find the latest version of the emulator? To steal from Dan Doore's message: Or have a go with the Win32 port of SimCoupe... http://www.podboy.demon.co.uk/coupe/downloads/wincoupe_alpha_080.zip ...and then get the latest snapshot EXE from Si... http://homepage.ntlworld.com/simon.owen/SimCoupe.zip; And is the windows version fully working? Pretty much so, yes - it should cope with virtually anything you throw at it! There are a few small issues in that version that have since been fixed, and a couple more things that are being worked on. I'll do another snapshot update soon, and hopefully update the docs etc. too so there's a single package to download once more. Next version will have slightly improved sound support, which improved the sound of the BEEP command and sound samples playback. Mono DAC and SAM DAC support is up and running too, so Stefan's MOD player sounds better than ever! After that there'll be some printer support (finally!), and more... Si
RE: Anyone help here
Chris White wrote: saw Wayne Hay other day ( incase you don't know him he did Pipemania on Sam for Enigma ) No showed him WinCoupe and he loved it , now he need a image ov Pipemania. What sort of copy protection does it have? Simple enough for a DSK or will it need an SDF jobbie? Si btw, your e-mail program is still set up to mark ALL your e-mails as high-priority! Could you please turn it off? Ta!
RE: Simcoupe 0.8 Alpha
Ian Spencer wrote: I know Si hasn't included foreign keyboards yet and my system is German. If your using an older EXE (named as WinCoupe.exe) then the symbols should be in the right place, but other keys that differ from UK/US layouts may be wrong. The newer SimCoupe.exe versions should do mappings for the other keys too (tested with the AZERTY layout with French keyboard layout). If it's still wrong with the newer version then I'll have to look into it - are (m)any non-symbol keys in different locations on a German keyboard? Whereas 1 to 6 work normally very strange! Has anyone else noticed problems? Very strange indeed! Hopefully you're just using an old EXE and can update yours with http://homepage.ntlworld.com/simon.owen/SimCoupe.zip. I'll see if I can reproduce it using a German keyboard layout on my system here... Si
RE: Shows etc
Dave L wrote: Weelll... that's 2 votes for November any further ones? :) November's fine by me... Horwich would actually be pretty convenient too - my other half can visit her mum while I'm at the show, as she lives just down the road :-) Si
RE: Shows etc
Justin Skists wrote: where's Horwich? NW of Manchester, near Bolton. See: http://uk2.multimap.com/m3/browse.cgi?scale=10X=365000Y=41gride=; gridn= I've been to Bolton loadsa times but I didn't know where Horwich was until I checked too! Si
RE: Completely off topic posting!!!
Howard Price wrote: Daveykins wrote: * 380w Speakers What the hell?!! I'm not sure I want a WindowsDing to go that loud. You must be pretty damn deaf, man. It's 380W PMPO tho, which is usually how they rate speaker to make them sound better than they are. Hi-Fi speakers tend to be rated in RMS, which is a lot more honest, and on that scale the 380W speakers would be roughly 25W RMS - doesn't sound quite so impressive!. My Crossfires are 100W RMS which gives a daft sounding 1000W+ PMPO! (you can tell I'm bored in work today can't you?) Si
Re: Sim Coupe
Dan Doore wrote: Si Owen and others are beavering away with SimCoupe to make it super-shiny, in the meantime members of this list can download the 0.8 alpha version from http://www.podboy.demon.co.uk/coupe/downloads/wincoupe_alpha_080.zip. Also, if anyone would like to try a recent binary, I've uploaded the latest snapshot to http://homepage.ntlworld.com/simon.owen/SimCoupe.zip Note: this is just a bare EXE so you'll need to have the older WinCoupe package mentioned above - many of the key mappings have changes, and I've not updated the docs yet! Also note that the EXE is now called SimCoupe.exe instead of WinCoupe.exe :-) Dave Laundon and I have been working very hard on it over the last few weeks, and hope it's faster and more accurate than ever. There aren't many known problems at the moment, and we'd would welcome any feedback on how runs compared to the previous version as well as anything you think that runs differently to the real beast. E-mail me if you have any problems, questions, suggestions, etc. Share and enjoy... Si
RE: Looking for old SAM stuff
Simon Cooke wrote: Umm... the parallax protection was kind of... tortuous. But it might work :) E-Copy can handle it (but then, E-Copy was spawned from the Parallax Disk Copier :)) It's certainly a lot easier to create an image from an original disk than to create a duplicate version of it anyway! Si
RE: Looking for old SAM stuff
Dan Doore wrote: This has reminded me of an earlier post about the SDF format that Win/SimCoupe supports - was there ever a SDF-maker around? I got e-mailed about that recently too, and the answer is 'sorta'! I did write some bits of program to do it, but it was only enough for me to know it worked, as it still requires lots of messing about to use it. I requires 2 drives and two floppies for each disk to convert, and for the BASIC part of it to be edited before each side of the disk is converted. Then the 2 floppies need to be converted to .SAD (not .DSK) format, and a binary editor used to chop off the 22 byte header, and the last half of the disk data. You are left with two raw binary sides which need concatenating to form the SDF image (well strictly a header needs to be added too, tho the latest released SimCoupe only understands files without them! Quite a lot of messing really - I've only converted about 5 disks myself so far! If anyone fancies taking what I've got and doing something better with it they're welcome to it! Otherwise I'll get around to it at some point, maybe once the next SimCoupe release is ready... Si
RE: Screen viewer 1.27
Dave Laundon wrote: Things I've been testing with that now seem to work - snip Big on-screen scrolly in Mnemodemo 1 (that was a tough one!) That's been eating at me for a LONG time, and I thought it would probably be one of the last things that would be unfixed! The boundary timings seemed pretty critical to get it visible, but there was still an extra fringe on the top and it didn't scroll smoothly. It looks really nice now - it seems your breaking down the timings to the fundamental workings is really paying off! There still seems to be a small problem with it, in that it looks slightly stretched just to the left of the right-hand border area. It seems to do that when the whole scroller is slightly too far left, so the preparation for the next line is done on the right edge of the screen instead of in the right border area. I remember seeing the same effect on border scrollers too, but all the ones I've checked are still fine. If there are any obvious ones I've not tried, let me know! Only other thing I've seen is that there's a slight flicker on the left side of the palette in Flash!, which wasn't there in the last version I had. Hopefully any minor things like that will all be caused by the same thing, so once it's fixed it'll fix em all! Great work Dave - I look forward to a source update and details of the mystical changes! Si
RE: Screen viewer 1.27
Edwin Blink wrote: If you need a a demo to test your timings I could send you my mode3/4 mode mixing demo (as featured on blitz 6) Thanks, got it from Dave Laundon. The SimCoupe version I have gets it pretty close, tho it seems to manage the mode changes 1 screen block too late in each case (see http://homepage.ntlworld.com/simon.owen/blt6menu.jpg). Not sure how Dave's latest CPU/timing changes will affect that yet... Si
RE: Screen viewer 1.27
Oops! Sorry about the name being wrong in the previous posts - first time I've posted to the list since I set it up in Outlook again! Si
RE: Wincoupe again...
Bob Wilkinson wrote: Thanks Edwin, but I have that version, it's the next release I'm waiting for, but it just seems a long time coming and some news would be welcome. It got archived away around New Year and was completely untouched until the middle of last month. A few people were interested in it, so I apologise to them, but it sounded like it was too much of a threat to the real SAM for people to be interested in it. The responses to the Millennium Poll asking how often is was used seemed to confirm the general lack of interest, so I lost all motivation to work on it and stopped. The fuss over releasing a GPL program without the source halted any further binary releases for people to play with - it was only ever given to people on this list as a private release, and not announced on any other sites. I'm not really sure whether people are still as anti-SAM-emulation as before - anyone want to speak up on whether it should be buried for a bit longer? It was only last month that I unpacked it and started to do a bit more on it... I've moved all the Win32-specific code out of the core modules, and am keeping it clean of any conditional code to avoid the usual unreadable conditional code soup. It's probably not completely settled down as there are some things I'm still not completely happy with, but it's most of the way there. It compiles and runs on BeOS, but with dummy versions of any OS-specific code so it's not of any use yet. Hopefully it won't be too bad to port back to Linux etc. but only time will tell - I still don't regret the revamp I've done on it. I'm back to calling it SimCoupe to show that it's more general, but will still probably refer to the Win32 version as WinCoupe if it's something specific to that version. I've added in support for MIDI out (port, interrupt and flags) to drive Windows MIDI devices (mainly for sound card synth playback) - thanks to Dave Laundon and his Mtracker app for helping me with this! Saving back to the various disk images is now hooked up too, so it's probably a lot more useful to most people that previous versions. The Atom support is still broken, as it has been since BDOS added CD-ROM support - all the ATA(PI) stuff is munged together and needs separating, as well as support adding for both master and slave. It's generally more advanced than it was in terms of emulation accuracy (instruction boundary timing support, etc.), tho I've not really looked to see how much of a performance hit it's made. On the Win32 side, the generalisation move has broken things like the option saving/loading (which was a quick (G/S)etPrivateProfileString implementation), and other new core additions may mean it's not running optimally at the moment. than it was since many people last saw it, but nothing drastic has happened in the UI dept. I've rewritten the keyboard code to cope with non-QWERTY keyboards in addition to symbols in different locations. Some of the video stuff still needs to be moved about, particularly some of the dangerous primary buffer access. I can reproduce the strange slow-down with 'Hardware support' enabled with my G200 in work (it's faster with it disabled), but haven't tracked down why it's happening. Preliminary Win9x direct disk access support is in, but it's very slow and shaky (damn the Win16 mutex!). I'm almost done with the WinNT/W2K hack, er, implementation, which is much faster and smoother than the Win9x version. I'm just finishing off the driver needed for it, which will also allow other SAM apps to use it to regular format access SAM disks (Edwin's utils etc.?), tho have a few side-effects to finish off to make it seamless. If people are happy playing with unfinished, potentially buggy test versions, I don't mind making them available as new features are added. I'm up for handing out the source in its current state, on request, and would welcome feedback and enhancements to it. I've yet to add in the GPL headers on source files and remove lots of commented test sections of code, etc. It's still under active development, and I'd like to maintain control the master source for now; I'd also like to keep control of official releases of it, and would prefer if there weren't unofficial versions floating about. Any objections? That about cover what were asking? (*runs for cover*) Si btw, my personal e-mail address has changed from [EMAIL PROTECTED] to [EMAIL PROTECTED] Upgrading to a cable modem at home has also meant my Demon web page has gone, tho I have got an new site to put things on, eventually.
RE: your mail
Simon Cooke wrote: To be honest... I couldn't find it either... I followed your directions, and couldn't understand anything that was there (it was all in Russian). I nosied around, couldn't find anything in English, Clicking on the British flag seems to make it worse! If you click straight on the Sprinter button on the left it seems to be ok. Or you can use this URL for the English version: http://virtuals.atlant.ru/peters/e-sprinter.htm Si (btw, Happy New Year/Millennium peeps!)
Re[3]: Christmas Greetings, etc.
Frode Tenneboe wrote: Ditto. Me too! Si
Re: SimCoupe's Spectrum mode
[Sorry for the delay in replying to this - I've been off with flu and not really up to doing very much!] Andrew Collier wrote: Just wondering will WinCoupe have the swame option as SimCoupe to emulate a Spectrum instead of a Sam? I put it back in a few weeks ago... And if it does, will it still have all the Sam's instruction timings and whatever? Yeah, everything's the same as SAM mode 1, except that it's seen as a real ROM chip so it runs uncontended - that might actually even make it even less useful than an emulator running in SAM mode as it's running too fast! It certainly doesn't use a Z80 clock of 3.5/3.54MHz or anything fancy like that! Would it make the code much simpler to take the feature out? It wasn't really much to add back in, so it's easy to take out - the only changes made were: - Use the Spectrum ROM image instead of ROM0 - Use a different keyboard table map so PC keyboard symbols locations are correct for the Spectrum - Border colour defaults to white on Z80 reset - SAM memory paging is prepared so LMPR and HMPR don't overlap. I'm just thinking it perhaps isn't massively useful to include direct support for the Sam to emulate a Spectrum, when you can achieve that by loading a Spectrum emulator in the virtual Sam machine Yeah true, and Martijn's excellent Spectrum emulator certainly does it a lot better! I used it for the first time recently, and it's a long way on from the simple write-protected ROM method I used to use! Alternatively, it's even better to use a 'real' Spectrum emulator (like Z80 v4.0), or even a real Spectrum if you're lucky enough to own one! I suppose the Spectrum feature doesn't really belong in a SAM emulator anyway. I can't imagine replacing ROM 0 with a Spectrum ROM chip will work on a real SAM anyway, as LMPR/HMPR are zero initialised on reset and therefore overlap. no disk support, no tape support. Literally all you could do was type in a few lines of BASIC (without the symbol-shift key). Well, there's better keyboard support in WinCoupe, but no disk or tape support. I didn't really think about it being so useless until you mentioned this! I guess it should probably be taken back out, tho the keyboard mode might be worth keeping... Anyone any thoughts/preference? Si
Re: Wincoupe
Simon Cooke wrote: The problem's this: Right-Alt, Right-Shift and Right-Ctrl aren't always available on all machines. (Some laptops don't have them - mine doesn't have right-ctrl or right-alt, for instance). Also, on European machines, Right-Alt is used as Alt-Gr to generate graphics characters for different language-layout keyboards. :) Alt-Gr is effectively Right-Alt (same scancode), as that's what my UK keyboard has (tho it often effectively presses left-ctrl too) - it's not needed for it's normal special character use on a SAM so it won't really be missed. As long as there is an equivalent key on most keyboards (I thought there would be) it shouldn't be a problem; if not then it'll have to go somewhere else, along with the INV (currently keypad enter I think). Does your keyboard have anything in the place of right-alt that could be the same really? Right-shift isn't really needed, but I use it in conjunction with Left-shift for something strange. On my UK keyboard is Shift-2, but pressing both shifts and 2 actually gives the copyright symbol, becuase the 2 and one shift are toggled when generating the SAM symbol, but the remaining shift acts on that to give the copyright symbol. Not terribly useful, but it helped me check some combinations and I thought I'd leave it in. Don't worry, I don't have Shift-2 hard-wired for - it should work normally wherever it's located on your keyboard! Right-ctrl is currentl used as an extra for SAM Cntrl, for when the left-alt option is disabled to use the key for menu access instead. It might be that users of keyboards without a right-ctrl will just have to suffer using left-alt (well, until Dave Laundon's key mapping idea is implemented - next e-mail!). Si
Re: Wincoupe
Dave Laundon wrote: Talking about customising the keys in WinCoupe, could we have options for customising the Insert/Home/Page Up block of keys? Yeah, nice idea... It can probably go in at the same time as clipboard pasting as it'll probably use some of the same tables. Maybe map Shift+Backspace to Delete, Inv to Insert and Cntrl+Left/Right to Home/End? Perhaps even Symbol+Edit (IIRC) to Num Lock. Shift-backspace for Delete is already in as I kept trying to use it! Insert is a much better choice for INV that I currently have, and the others are good and general too. I've also put the Spectrum keyboard mode back in, and added as many normal key combinations as possible to it; only the extend mode symbols are not available on their usual keys. I suppose this calls for a SimCoupe.ini file... Already got a WinCoupe.ini! Uh-oh, not back to that discussion again... How about the MIDI ports? How easy would it be to interface with the Windows MIDI devices? I reckon it should be ok, but I'd not looked into it as I've no SAM software that drives the MIDI port for music. I've done more work on using the MIDI port for network access (over TCP sockets), but it's not at a very useful stage yet. I have a program that plays E-Tracker tunes out of Sams MIDI port. If you're willing to send me your program, I'll take a look once I've tied up some more loose ends... Si
Re: Wincoupe
Andrew Collier wrote: One idea you could consider, which Ian described to me (I think he'd used it in his X spectrum emulator) would be that Left-Shift produces the keystroke you'd expect from looking at your PC's keyboard (eg, left-shift and '0' gives ')') wheras Right-Shift directly corresponds to the Shift key on the Sam (eg, right-shift and '0' gives '~'). I tend to use the different shift keys fairly interchangably when typing, depending on what I'm shifting to get at, which would give very strange results! Instead I've got 3 keyboard modes to choose from: 1) Raw, which doesn't do any magic, so shift-0 gives ~ (as on a real SAM) 2) SAM mode, which does SAM-specific key translations so shift-0 gives ) (as on the PC) 3) Spectrum mode, which does Spectrum-specific key translations, so shift-0 gives ) with the Spectrum ROM or | in SAM BASIC (from symbol-9 as needed by the Spectrum) Switching between SAM and Spectrum system modes in the menu automatically selects the relevant keyboard mode, but you can override it after that if you like. Then again, not all keyboards can distinguish between left and right shift, including all USB keyboards I've tried. Some of the Win32 keyboard functions don't distinguish between left and right versions, except under NT/W2K. WinCoupe uses DirectInput for keyboard reading, which gives a table of raw key states in scancode order, and does distinguish between left and right versions on all platforms. I've not got access to any USB keyboards to try it out... if they're cheap enough I might give it a try! Frankly, the idea of implementing all this on the iMac is giving me nightmares... Join the SimCoupe nightmare club! ;-) btw, did you ever ask Richard Bannister about the MacCoupe (hehe!) source code? From what I remember, he was offering to pass it on to someone that could continue to develop it... Si
RE: Wincoupe
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
RE: WinCoupe DosCoupe
Aley Keprt wrote: Yea, you probably want me to change the name of my stuff to DosCoupe... :) :-P~~~ Si
Re: WinCoupe: frameskip auto
Aley Keprt wrote: I still don't understand why frameskip auto shows higher fps values than frameskip none. snip I'm affraid that number shown in the window's title bar shows number of frames rendered and skipped together. And that IS nonsense. Ah, I see what you mean, and I completely agree! It was more of an indicator to show general relative SAM speed, with 50fps being normal. It does give an idea of how fast it's running, but it's a bit misleading! I actually changed it a couple of weeks ago, and split it into a percentage to show relative SAM speed for the emulation, and a separate figure for the number of rendered frames per second. Fast machines will manage 100% with 50fps, and slow machines should still manage ~100% but with a lower fps as frames are skipped. btw. WinCoupe's about message says: SimCoupe - a Sam Coupe' emulator So is it WinCoupe or SimCoupe? WinCoupe seems to be more of a nickname for the Win32 version of SimCoupe, and I started using it after a few people referred to it as that. It seems to be easier to call it that so people know which version you're talking about, so I think it's gonna stick - I'll update the about box. It's still SimCoupe underneath, and when the source is ported back to whatever it'll still be SimCoupe... Si
RE: Wincoupe
Aley Keprt wrote: My should know that my technology is generally better. It uses the system of audio drivers, so it allows to do several advantages. Better in what sense? WinCoupe uses DirectSound, which uses specific drivers (usually) written by the sound card manufacturers, so it should give better support than the general DOS-style drivers. I can't imagine card coverage isn't really too much of a problem anyway, as most people will have something that's SB compatible. 5. It works with Aztech soundcards. I don't know why you tell that it doesn't. You probably misunderstood the documentation. The docs say: Note that SAAemu currently support mixer in SBPro mode only, so it doesn't work on some Aztech soundcard models. which seemed to suggest that there'd be a problem with some cards. Generally, current SAAemu can hardly match SAAsound's quality, but it can be enhanced. And that's it. You can say: Enahance it and then I will include it in SimCoupe. But is this right way? If it was enhanced for envelope (etc.) support and to work on all platforms then I feel it'd be a lot more useful and would be worth using it. Without those I imagine it'd just generate too many support questions and source code complications. Maybe I'm just too much of a perfectionist and don't want to settle for 2nd best - I want the most accurate and complete emulation possible in every respect! This is clear. I would to know how does it work: Do you create a whole 320x240 or 640x240 image everytime and then use blt to put this stuff to videoram? Or do you put there line by line using separate blt's? It generates the display in a back-buffer line by line, and blits the entire image to the visible display at the end of the frame. The image size is either 320x240 or 640x240 depending on whether the accurate mode3 option is enabled (actually, it's stightly taller now to show more of the vertical border as would see on a real SAM). Of course, if the frame is being skipped it doesn't do any generation or blitting. Do you emulate on-line video changes? (I mean when the ray is on line 100 and I change something on line 50, it shouldn't be visible.) Yes, it uses a finer grained version of the original method, and follows the raster scan down the display. If you change the palette/border/vmpr as it's part way through a horizontal scan, the remainder of the line will be drawn with the new settings (if applicable). It allows fancier effects to be displayed correctly but is more likely to reveal flicker where the instruction timings aren't quite correct yet - something the old updating method masked. Data changes (writing to the display memory) are not updated as accurately, but are still correct for within 1 scanline, so you will still see shearing if you're updating the display as the raster passes the update position. Without the current forced update at the end of a line (something I hope to change for accurate data changes at some point) some demo star-fields are not visible, as they have already been removed by the time the display is updated at the end of the frame! 2. Windows version is much faster generally since it uses video acceleration. Video acceleration gives more than anything other can take. Right? Most modern cards do support it but older and cheaper cards may well not, so they have to fall back to using the DirectX software emulation which is more CPU intensive. The new 5:4 aspect ratio option will be a breeze for system with hardware support or fast processors but will be appallingly slow on older systems! It's rather ironic that the machines least likely to have hardware video assistance will also be the ones with slower CPUs that will struggle more with software blitting! Si
RE: Wincoupe
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+F11Toggle 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. oo 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
RE: Wincoupe
Aley Keprt wrote: I don't understand why so many Win32 programs are called a) Winsomething b) Windows something c) something32 Just seems to be the normal convention to distinguish between them from non-Windows version, in the same way that Unix programs for X are xsomething. Filenames are just textual labels, so if they tell us more about the file it's a bonus! It was confusing having an EXE with the same name for the Win32 version, and which also meant I couldn't have them both in the same directory to share ROMs etc. I first called it SC32.EXE (option c, but avoiding long filename!) but later changed it to WinCoupe.exe (option a!) as that's what other people were calling it. The nickname and filename have just stuck as that. As a side-effect it also means that SAM programs that say 'this doesn't run on SimCoupe' are still correct, even tho they do :-) So I preffer SimCoupe for Win32. That's fine... Call it Squiggle if you like - anything that makes it easy to know which version is being referred to for problems/praise etc.! Si
RE: Wincoupe bug
Dave Laundon wrote: First, I still can't seem to get the MOD Player to work. Was this supposed to have been fixed? Or is it still being worked on, Dave? This one's been fixed - it was a bug in SimCoupe itself rather than in Dave's DLL. It still had the original code doing an absolute compare for the sound register address, rather than an a mask and compare, which the MOD player seems to make use of. The bug is still in the alpha version on my site, but I'll sort out a 2nd release early next week when I'm back. Another sound bug, playing tunes which have envelopes enabled for saw waves, etc (eg, a lot of Roger Hartley tunes) the enveloped channels sound out of tune, especially at low frequencies. I'm not sure about this one, but Dave has made some changes to the envelope stuff recently that might include it. Try grabbing the latest version from: http://www.geocities.com/stripwax/ to see if it sorts it out. If it's not that it might be another bug in the previous WinCoupe version, which only called through to SAASound.dll when the data register was written to; register selection writes were just cached for the register to use next time data was written. This was wrong as multiple writes to port 511 do seem to affect the sound output (in a way that I don't really understand but Dave proved to me!). Now an idea for Wincoupe itself: I think it would handy if there was some indication, perhaps on the title bar, of when the disk drives are being accessed, so during some long pauses I can tell that it's not crashed. Yeah, I did think Lemmings had crashed when the music stopped and I couldn't move the mouse, which felt rather like Windows had crashed on me! I've not added motor off support (after 10 revolutions or something) to the floppy controller, but do have some green lights planned for the edge of the screen - something I've seen on an Amiga emulator I think. maybe you could even mimic the screen dimming as the drives are spun up! ;-) hehe! And adding a buzzing to the sound output, especially when the drive is stepped (it does that one my real SAM anyway!). BTW, I think WinCoupe is excellent and I LOVE IT :-) Si
RE: Wincoupe bug
Dave Hooper wrote: I was actually thinking of emulating the sound interference you get when the disk drive is going :) (Seriously ! Would it be a cool idea, or just stupid?) Might be nice as an option! ;-) In what way would you change the sound when it's active/stepped? Si
RE: Wincoupe bug
Robert Wilkinson wrote: Wincoupe has a wierd effect on my Win 95 desktop. It keeps re-arranging my icons. It it re-arranging them to a 320x240 rectange in the top left of your desktop? (so anything further down or right is pulled into that rectangle). I've only seen that happen when DirectX wasn't exited after full-screen mode has been used - seems ok on mine tho... hmmm. Does it happen if you start WinCoupe, switch to full-screen, then switch back to windowed mode with F9, and quit? The video change detection in that version is a bit too aggressive, as I noticed it won't even let you alt-tab out of the program! It could be related to that, so hopefully the next version should sort it out. Si
Re[2]: samdsk
Frode Tenneboe wrote: Si Owen [EMAIL PROTECTED] wrote: as the NT based versions of Windows are the future of MS Windows. FLAMEBAIT I didn't know it had any. :) \FLAMEBAIT Go get him Aley! ;-) I was careful not to just say 'the future of windows'! W2K is close to complexity critical mass by the sounds of it, so it'll probably explode before 2001. Si
RE: samdsk
Justin Skists wrote: If I remember rightly, the program gave 9 boxes and an X for each track. My SAM certainly did not like booting the resulting disks... Ah, so it can't read the 10th sector. I think you need the special version of FDREAD to allow access to the 10th sector... I'm determined to play with these utilities and games that I downloaded whether it kills me or not I've been using Aley's 2SAD.EXE with the -s option to convert from .DSK to the normal uncompressed .SAD files, then using his SBK.EXE with the 'r' command to write it back out to a real floppy. All best done from real DOS or Command-prompt only mode outside Win9x (not on NT!). Both those utilities can be found in: ftp://ftp.nvg.unit.no/pub/sam-coupe/emulation/simcoupe/SimCoupe079_DOS.zip It shouldn't be long before you can do it all from within WinCoupe, by selecting the source .DSK image in one drive and the real floppy drive in the other, then just doing a normal SAM disk copy between them... Si
RE: samdsk
Justin Skists wrote: If I had so much trouble with this from NT4. How is doing it all from WinCoupe going to help it any better? Well, just as an abstraction layer to hide the conversion details; you can convert between DSK/SAD/SDF and real floppy just by copying disk to disk in the same way you would do on a real SAM. That said, the initial support is for Win95/98 only, as NT4/2000 will require a separate device driver to provide the functionality that the standard floppy kernel-mode driver lacks. It won't get done straight away, but I'd like to see it done at some point, as the NT based versions of Windows are the future of MS Windows. Si
Re: Wincoupe
Aley Keprt wrote: there are probably some weird bugs (in SimCoupe). I'm sure there are bugs - that's why it's an 'alpha test' version! (for SAM-users list members only). I've already found and fixed various things that were discovered since that version, but there are bound to be others. Before making that version available it was only tried on 3 different PCs! mode 3 on --- 175fps with skip auto --- 142fps with skip none mode 3 off --- 50fps with skip auto --- 25fps with skip none Firstly, I hope it's obvious that it shouldn't run that slowly, so there's a problem! Does disabling the 'Hardware support' option still give similar results? Are you sure you've got the 'mode 3' state correct there? There is a problem with having the mode 3 option enabled when using the 1x1 window that caused can cause big slow-down (already fixed). If your display driver supports hardware stretching WinCoupe tries to create the DirectDraw back surface in video memory so it can use it. However if it doesn't support hardware shrinking then DirectX uses software emulation to provide the shrinking. Reading from video memory is extremely slow, and the emulated blit requires many reads from the source image to do the shrinking. I've can only reproduce this with the TNT NT drivers, as the Win9x drivers DO support shrinking. 1. I though skip none should be the fastest. I can see skip auto is faster. A bug? 'skip none' means it generates and displays ALL frames, even if it means the emulation will be running under real SAM speed, as it will on slower PCs. With the frame sync enabled, 'skip auto' skips as many frames as is necessary to keep the emulation running at 50fps. At the end of each frame it checks to see if the next frame is overdue (because the current one took too long), and if so it skips the following frame (i.e. doesn't generate the frame data or blit the image). With a fast enough PC no frames will be skipped (well, the odd one might be if other Windows apps steal away too much CPU time). It will still drop below 50fps if the image blitting is taking an unusually long time, or if the system is too slow to even be able to run the CPU emulation with the 1fps video generation (the minimum allowed). With the frame sync disabled 'skip auto' will give the same effects, but only if the PC isn't up to running at 50fps with the 'skip none' option. With faster machines it doesn't work in the same way, but just happens to skip some frames, so it'll still be faster than 'skip none'. Well, menu has no shortcuts. I want at least Alt+Space to enter the menu. The current Alt functionality is actually exactly how I intended it to be! Left-Alt is used for the SAM 'Cntrl' key, as it's in about the same position on the keyboard. The menus can't be accessed directly using combinations like Alt-F because the combination needed for cntrl-f on the SAM (as used by TurboMON and more). I purposely left the menu text without any accelerators to show they can't be used. I put in some special cases for Alt-Tab, Alt-Esc and Alt-Space (tho this last one seems broken!) so they can be used for their normal Windows operations. To access the menu you just have to press and then release the Alt key (or F10, as Windows automatically uses that too), at which point it will be highlighted (full screen mode too). You can then use the mouse as normal (even when the SAM mouse is enabled), or press the initial letter of menu you want to open (space for the system menu), or just navigate using the cursor keys and press Return on your selection! To keep everyone happy I've now made the use of Left-Alt as SAM Cntrl optional. The PC right-Control key is also the SAM Cntrl key, so that can be used to generate the combinations when Left-Alt is used exclusively for Windows. Dirty lines are too complicated? It's because you've probably did too optimised video code. If you think you can do better then you'd better get to work on enhancing 0.79 (you obviously wouldn't want any of my crap code). You might then appreciate how much time and effort I've put into it so far. I can imagine your sources. :-))) Well, have fun imagining... ;-P Mame uses dirty rectangles (the thing you call dirty lines) and it benefits from it. You're right, that it can slow the whole emulator. But how much? A little bit. Even the old simple method potentially is quite costly. EVERY memory write needs to be examined to see if it falls within the display area of the current screen mode, and if that's true then the something needs to be done to ensure it's updated next time. The simple case just sets a flag in a line array, but if you really do mean rectangles then it'll be a LOT more costly! General solutions are fine for the general cases, but I felt that more could be gained by examining the specific SAM case. Just one change to border, palette or vmpr within a frame requires that the full frame be redrawn to reflect the change.
RE: Wincoupe
Aley Keprt wrote: Hey, you are the man who could use SAAemu instead of SAAsound in SimCoupe. Si Owen doesn't believe but this is really true. For ferks sake Aley, if you have to quote me will you at least try and include what I actually said or at least something that resembles it! To quote the e-mail I sent you, in reply to your request that I add SAAemu support to WinCoupe I said: To be honest I don't think it'll be worth using anything other than ave[ Hooper]'s DLL. The synth version isn't as accurate, and lacks the high resolution changes needed for sound samples, and the Spectrum beeper support used by the SAM BASIC sound effects. My reasoning being: Benefits of the synth version: - Faster than the SAASound.dll Drawbacks of the synth version: - No support for Windows NT or Windows 2000 - No support for the rapid audio changes required to play sound samples - No support for the Spectrum beeper used for the BASIC error rasp, the beep/zap/pow/zoom commands, and Spectrum software - No support for envelope effects - Noise generators aren't emulated correctly on OPL2/3 sound drivers, due to OPL2/3 inability to play white noise. - Envelope-ctrl is used only to override the channel-mask bit, so some tunes still play even if you mask out all the channels. - Doesn't work with all sound cards (includes some Aztech cards) It's a perfect case of not getting anything for nothing - yours is fast but lacks features is inaccurate, Dave's is slower but fully featured and very accurate. The DOS version of SimCoupe is faster than the Windows version for exactly the same reason - the instruction timing and video generation code in the Windows version is much more accurate (along with lots of other bits that don't directly affect performance). DOS SimCoupe cannot use all that hardware acceleration of the latest video/audio cards, but it can still run well on P100. Actually, the only thing in WinCoupe that gets hardware assistance is the image blitting, and that's only when the card supports it; the audio side isn't accelerated in any way. The main advantage the Windows version gets is the hardware /abstraction/ through DirectX. If your machine is up to running the Windows version, then I'm sure you'd want perfect sound emulation with it! It reduced the maximum frame rate on my work machine down from 113 to 108 (about 4%) when enabling 22kHz 16-bit stereo sound, which is is peanuts. If a machine isn't up to running WinCoupe, even with the frame skipping (I can't imagine a P100 is!), then you're probably better off sticking with the DOS version, which already includes the faster synth sound emulation. Si
RE: Atom
Martijn Groen wrote: I'm currently working on B-DOS 1.6c ( version up to 1.5 were made by Edwin Blink, so credits to him!) B-DOS 1.6c has nice ATAPI CD-ROM support. Is there a version later than 1.4e available from anywhere? Si
RE: Wincoupe
Robert Wilkinson wrote: My machines a 166 pentium. Wincoupe needs a faster machine than this, needs a zimmer frame to get around in this machine. hehe! Try using fullscreen mode and making sure the 'accurate mode 3' option is disabled. That will use 320x240 mode which requires no image stretching, so it's the fastest it'll go! Not sure how it'll compare to the speed of the DOS version under the same conditions tho. With the 'accurate mode 3' option enabled it uses 640x480 which requires the 2x1 generated image to be vertically doubled by the display driver. Unfortunately you can't see the window title bar in fullscreen mode to know the speed, so you'll have to guess how well it's running - on-screen display is coming soon to solve that! What the maximum framerate do you get on the startup screen with the 1x1 window size and the 'frame skipping' set to 'none'? It's unfortunate that the only 2 machines I use are a PII-400 in work (S3 video card with no hardware help) and a (dual) Celeron 550 at home (TNT video card *with* hardware help). With the 1x1 window I get 167fps in work and ~307fps at home, so I hoped it would be ok on something like a P166 even tho I hadn't tried it out! I can't get it to drop under 50fps under any conditions at home! The frame skipping tries to make up the extra time to keep the underlying speed the same, but if the screen blits are taking far too long it can't quite compensate enough! Slow blits also make the keyboard less responsive as it's possible for keys to have been released before the keyboard scan sees then (and using keyboard buffering only leads to lagged keys which are awful in games!). I've (possibly contraversially?) removed the dirty line checking from the memory and video code, as the frame skipping and high resolution updates made things too complicated. About the only drawback is that you no longer get a speed boost when no video, palette or border changes are made in a frame, but the frame skipping should cover those cases unnoticably anyway when things are running below normal speed. I reckon most SAM software didn't really benefit from it anyway, and it also resulted in more of a speed fluctuation during use. With the tests removed all memory writes are a bit faster which benefits things as a whole. The only loss I can think of are possible inter-line 'pixel effects', done by writing data to the screen close to the raster position (not including VMPR, border and palette changes which are still done accurately). The undrawn part of each line is still updated at the end of the line to ensure to sure that they're not more than 1 line behind - without this it magically removes the star field from some demos! Looks very good though. :-) It's getting there! Si
New WinCoupe alpha test version (Was: Re: Defender)
Simon Cooke wrote: Mr. Owen... pretty please... release a new beta? alpha? anything? Aw, go on then, as long as you promise the GPL goblins won't come and get me! I've uploaded a new alpha test version to: http://www.obobo.demon.co.uk/WinCoupe.zip Please read the text files that come with it, and also note that it doesn't save disk changes back to the image file in this version, even though the image in memory IS updated! Well, that's what you get for having a test version! Please let me know how you get on with it, as feedback (positive and negative!) is much needed at this stage! There are still a few more things to add, but probably not a huge amount for the upcoming version. I think I'm still on target to release the sources at the end of next week, after some general tidying... (and may then start working through the next to-do list of features!) H... I've got to be up in 4 hours *sigh* Si ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/
RE: New WinCoupe alpha test version
Simon Cooke wrote: especially as somehow it manages to play samples back Just careful line and cycle counter timing for the gap between each out, and calls to Dave superb sound DLL to generate the data itself. I'd already done the video generation using the same sort of method so it wasn't too bad (well, after the initial pulling out to figure out the buffering!). (but not Modplayer stuff). Really? What does it do? and where can I find some MODplayer stuff?! There's something decidedly weird with the sound emulation though - NT 4 shouldn't have those problems (ST_SOUND works fine, y'see). Might be my sound card drivers or the fact that it's an ISA card, but I've seen lots of other latency complaints with NT4. I allocate a single static secondary buffer x times the size needed for a single frame of data, and just top it up during after after each frame. My logging even confirms the buffer stays almost completely full! I even checked it by saving the sound data for a pure note to disk, and the WAV file is perfect but it plays with clicks in it! I might try installing NT4 at home with my SB Live! to see how it is (I usually share the same installation between home and work on a removeable hard disk). It's fine under Windows 2000 RC2, but that's got all the updated DirectX code in it! I'll have a look for ST_SOUND tomorrow and give it a try in work! also, on the SCPDU 6 demo, the vubars are too far to the left. FLASH looks odd too... There a many more of them too - all caused by the instruction timing for the main screen area not being right (it's a very poor approximation at the moment, but will be improved very soon!). Any very timing sensitive main-screen or bottom border effects run too quickly, so the on-screen effects are usually a bit scrambled and the bottom border effects are shifted left (but should be aligned perfectly vertically!). Ironically it's the accurate video code that's uncovering things that the previous line method masked! I'd like to go through most of the Z80 instruction set and do on-screen timing to try and sort them out. A lot of the visual glitches will be cleaned up pretty quickly, but some (like the VMPR scrolly in one of the Mnemotech demos) might end up relying on instructions split across contention boundaries which will be harder to solve! The border timing should be pretty good (thanks to people on the list!), as will the screen-off timing (as relied upon by Defender!). The external memory and ROMs are correctly uncontended too - the system reset is very slow if the ROMs are contended! But we're getting there. Shame it took so long - if only I'd not had the summer off! *grins* Si - Nice work on the floppy drive emulation. I'm kind of surprised - loaded up SAMDice, and it gave all the right kind of info for a track read :) You damn silly fool :) It's not something that's really very useful but I couldn't resist it! I'm still doing the WRITE_TRACK data parsing that's needed for formatting correctly (currently it reports 'write protected' if you try a format). The READ_TRACK data is a bit too accurate in some way too, as the read controller seems to trip over particular values (46 or something daft) and appears to get the MFM decoding out of step after that! The general structure should be ok, even the header CRCs are correct with SDF images! Si
RE: SOLUTION: SAASound.dll ; SAA32.exe ; Saaemu0.60
Aley Keprt wrote: 1. Add SAAemu.lib to your project. 2. Include SAAemu.h in your source code 3. Use functions of SAAemu in you program Since you're distributing SimCoupe 0.79 with this, I presume you'll be releasing your sources as required by the GPL? Are you all beginners or what? You should understand this, when you programm in Win32. ? Lemme guess... it's an extract from your forthcoming book How to get along with people? Si ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/
RE: Re Finally
Si Cooke wrote: You'd get richer from: POP AF RET I've always blamed myself being poor on investing heavily in: DI HALT Si
RE: SAD Disk format?
Si Cooke wrote:
By the way... does anyone have any documentation on the SAD format?
Never seen an official spec either, but here's what I use:
#define SAD_SIGNATURE Aley's disk backup
// Format of a SAD image header (22 bytes)
typedef struct
{
BYTE abSignature[sizeof SAD_SIGNATURE - 1];
BYTE bSides; // Number of sides on the disk
BYTE bTracks;// Number of tracks per side
BYTE bSectors; // Number of sectors per track
BYTE bSectorSizeDiv64; // Sector size divided by 64
}
SAD_HEADER;
Followed by actual data: side 0 track 0, side 0 track 1, side 0 track 2,
etc. So data for the second side of the disk (if any) is slightly more than
halfway through the image file. DSK images (as well as lacking the header)
interleave the tracks instead, giving: side 0 track 0, side 1 track 0,
side 0, track 1, etc.
SAD version 2 is just the same but gzipped up.
Si
ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/
RE: Sam IN / OUT timings
Si Cooke wrote: Have you tried out the Auf Wiedeshen Monty/SCPDU 6 demo from the Entropy Experience disk yet? Because all the source code to the border scrolly on that is available... :) (that, and I'd love to see a screen-shot of it ;)) I transferred the original disk over to a SAD again and SBK complained about track 79 on side 0 being unreadable. It just hangs with a black screen when I try a BOOT, but the original disk boots in a real SAM. It's either a SimCoupe problem or the disk is a funny format that SAD can't cope with... Still, a BOOT 1 works and I can load the demo. Check out: http://www.obobo.demon.co.uk/scpduys.jpg Scroller runs great, and the bars at the bottom are stable (just slightly too far left - I've not had a chance to do the instruction timing tweaks (from Ian and David) so it might just be that). Si
RE: Sam IN / OUT timings
Si Cooke wrote: Hmmm... it sounds like a Simcoupe problem; the disk is standard format; the only real difference is that I've got my QDOS on the booter; so does that come up? The QDOS booter is fine, it's just when loading after that. The last thing it reads on the disk is side 0, track 52, sector 2 - it also gets stuck there when loading some of the other stuff, which suggests a corrupt data somewhere! It does the same on the DOS version so it's not anything I've broken. I'll try writing the SAD back to a disk and see if it works on my real SAM (it's decided the display will only be shades of green today!). Si
RE: Sam IN / OUT timings
Andrew Collier wrote: The stretching effect is just the right hand side of the scrolly -- because I had assumed a TV doesn't display further right, Ah, yeah, I stepped thru it and found the preparations for the next line :-) So... that scrolly was written on the assumption that the left border is no bigger than 24 pixels wide, and the right border is no bigger than 16 pixels wide. It's 32 on each side at the moment, which is half of the potential border area. Might be worth chopping down to avoid seeing problems that don't really exist! Is a typical TV border only 16 pixels? I'll have to check mine... I reckon there should be something like 40 pixels at the top and bottom, but less at the sides than you've already got The current 24 pixels top and bottom is quite a bit short of that! It's probably worth generating the extra lines as they can be displayed in the windowed mode and just cropped for full screen. The 125% horizontal stretching you mentioned in a previous message could also be done for free if the video card supports hardware stretching, but would be deadly slow if it needs to be done it hardware. It might look awful anyway so I'll have to try it out first! In my menu for FRED issue 65, there's an effect underneath the border scrolly which goes to just about the bottom of my old TV display, if that helps. I've only got FRED disks 37 and 37 :-/ Shame there isn't a CD compilation of them for sale or something! Yes, it does look like an 8 tstate rounding thing going on. Thanks for the results - the uncontended timings and I/O delays seems to be working well, it's just the contended timings that are complete pants! The simple doubling causes problems with a lot of software (even with the exceptions mentioned on the list) so I'm going to stick with 8 t-state rounding and add extra time for the more memory intensive exceptions. In the end it may end up simpler with time doubling and reductions for the exceptions but I'll have to see. How many comparisons would you need to do in order to determine if the instruction covers the transition between contended and uncontended operation? I have 2 flags for the current contention: the first is recalculated once per line (or on each video change) to determine whether the current line might be contended (checking screen on/off state, for mode 1, and vertical position wrt the borders). The second it done for each instruction iff the first flag is set, and checks for mode 1 and horizontal position wrt the borders). For a split check: if the first one is set (and we're not in mode 1) we need to check to see if the current position + instruction time pushed it over the borders at 64 or 320 cycles. Could be done something like: (64 - tstates) (LineCycleCounter 64 ? LineCycleCounter-320 : LineCycleCounter); Si
RE: Sam IN / OUT timings
Si Cooke wrote: Have you tried out the Auf Wiedeshen Monty/SCPDU 6 demo from the Entropy Experience disk yet? Because all the source code to the border scrolly on that is available... :) (that, and I'd love to see a screen-shot of it ;)) Do you have a disk image of it anywhere? I've got a .SAD version of 'The Entropy Experience' disk I got from you that time I was in Tyldesley, but it seems to be corrupt - if I load the SCDPU-5 BASIC program on it I just get a listing of rubbish. :-/ If I can find the real disk one from the loft I'll give it another try... Si
RE: Sam IN / OUT timings
Andrew Collier wrote: 16* uncontended t-states for an IN a,(n) or OUT (n),a; 20** uts for an IN a,(c) or OUT (c),a. Question: Does SimCoupe currently use those values for the instruction time? Not quite so fixed as the position in the scanline can vary the timings by 4 t-states. I currently still have the raw timings for the instructions in the code (i.e. 11 for IN A,(n), 12 for OUT (C),r and 16 for OUTI) but then tweak the values as necessary by the display position and state. At some point I'll wrap the 'tstate' variable assignment macro to get the values to be compiled to be 4 t-states rounded to save doing it at run-time. The current implementation does 8 t-state instruction rounding for all parts of the mode 1 display, or just for the centre 256x192 block of the screen in the other modes when the screen is enabled. The remaining situations use the normal 4 t-state rounding. I treat mode 2 the same as modes 3 and 4, except the screen can't be disabled - am I right in thinking the timings are the same. For all the instructions that do port reads and writes there's an additional 4 t-states that are added for situations when the current scan position is not already 8 t-state aligned, and only for ports = 0xe0 (from Si Cooke). Additional timings values I'm using that make a big difference for some software are: IM0/IM1 time = 8 t-states, IM2 = 16 t-states (rounded), interrupts active for 120 t-states and visible on the status port for 102 t-states (thanks for all those Ian!) and line interrupts are triggered at the start of the right-hand border area (line cycle position = 384-64 = 320). I've removed all of the original timing tweaks that were in the code for whatever reason as they only seemed to break things - I was hoping to do without any but we'll see how it goes. All these have help it survive various small timing tests done by various people, including the now infamous Defender loop ;-) Now I've implemented the display changes (border, palette and/or video mode) to instruction level it's possible to see how it copes with some of the SAM demos that rely on perfect timing. In general it seems to cope quite well, but there still seem to be some subtle timing issues that means the left-right positioning isn't quite right (not looked into yet). Effects in the border seem to run at the right speed, but ones on the main screen area run a little too fast. Here are some screenshots and problems (20-30K each): Mnemo demo 1, part 2 (http://www.obobo.demon.co.uk/mnemo1p2.jpg). The bottom border display stays synchronised correctly but it's left-right position isn't correct. The scroller on the main screen uses rapid VMPR switching, but the diagonal pattern shows it's running too fast so it's not lined up correctly, so some additional delay is needed. Mnemo demo 2, part 2 (http://www.obobo.demon.co.uk/mnemo2p2.jpg). Scroller lined up ok, but the right hand edge has a strange stretching effect for the edge of the character (and 'o' in this case) that's appearing. Mnemo demo 2, part 3 (http://www.obobo.demon.co.uk/mnemo2p3.jpg). Bars in bottom border jump left and right by 1 to 2 blocks worth, and the misalignment give additional lines that should probably be aligned with the bars (?). [it doesn't just run at 11fps as the title says, I'd just unpaused it and it hadn't settled]. E-Tunes demo (http://www.obobo.demon.co.uk/e-tunes.jpg). VMPR switched scroller now visible, tho the start position is slightly to the right and it's also a couple of blocks too short. Lyra 3 (http://www.obobo.demon.co.uk/lyra3.jpg). Top scroller seems to run fine, and bottom static image is shifted to the right. The other visual artifacts I used to see (where the screen should be disabled to hide stuff?) are no longer visible :-) The current SimCoupe doesn't seem to show enough of the border areas (mainly top and bottom) to show all of the border effects, so it might be worth having windowed modes show more of them (possibly optionally). 'ESI' in Lyra 3 does look rather like 'FST' :-) Summary: OUT (n),a OUT (c),a IN a,(n)IN a,(c) VMPR 16 *20 ** 16 *20 ** Those values fit the case when the scan position isn't 8 t-state aligned, since the extra 4 t-states is being added to both (of course, there's no 8 t-state rounding to consider in your tests). If you put a NOP before the other instructions I'd expect you to get the same timing result, as the NOP will add 4 t-states but there won't be an additional 4 t-states to add for the alignment - would you please be able to try it? I've noticed that some places where the video timing isn't quite right seems to involve DJNZ for tight delay loops. The width of the scroller section used by the E-Tunes demo is mainly just one such loop. Is there anything special about DJNZ in terms of timing that could cause it to be too fast? I'm also starting to wonder about instructions lying across the boundaries where memory
Re: SimCoupe 0.79
Aley Keprt wrote: 2. new floppy interface, can read/write GZipped SAD images!!! Is SAD version 2 just SAD version 1 in a gzip archive, or are there any other structural changes? Is gzipped DSK support too, as they're more commonly used. note: SAAemu 0.60 is now available in Win32 version too. (I hope it will be included in the first Win32 release of SimCoupe. .Who knows.) I was waiting to hear back from you about it - is there anything I can try? I'd be interested in seeing Dave's hq stuff in action, but I've not got enough interface documentation to use the DLL you sent me a couple of weeks ago. What's the sound latency like - is there much lag when playing games? (crashes when run under NT so I'll try it tonight...) Si ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/
Re: Vortex Assembler - Update
Back in March, Si Cooke wrote: Well, the assembler is proceeding apace... features so far include: surnip Was it ever finished? If not, is it still being worked on at all? Si ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/
More SimCoupe timings (was: Re: Defender on SimCoupe)
David Laundon wrote: NOPs removed HL on exit (sometimes varies by 1 between calls) 0/15d8 2/367e 4/574e 6/7859 8/99bd 10/11 bb0 I changed the uncontended timings to round them up to the next 4, as they should be, and I was getting values that were slighly higher yours. This was tracked down to being an error in the original 12/16 condition in the IN A,(n) implementation. The original code was: if (LineCycleCounter % 8) tstates+=4; which adds an extra 4 t-states if the cycle counter is not a multiple of 8. After this is done the original 12 t-states is added giving an instruction total of 16 t-states. However, since the original value wasn't 8 aligned, the new value isn't aligned either, so it's mis-aligned for the next instruction, which is wrong. The fix was just to reverse the condition to: if (!(LineCycleCounter 7)) tstates += 4; Since an iteration of the main loop is 80 tstates (a nice multiple of 8) once the LineCycleCouner value is aligned it remains aligned, so (all INs take 12 t-states and the loop works fine - I now get exactly the same results as you for 0 to 11 NOPs. Naturally I thought that would mean the Defender loop would also be correct, but strangely it wasn't (tho IX was a consistent 0x4848). I single stepped through the first few loops and it was 80 t-states per loop as expected, but it was only doing 1481 iterations instead of the expected 1496. After a lot more logging I noticed that some of the INs were taking 16 t-states, so something was knocking the LineCycleCounter alignment out. The culprit was: if (LineCycleCounter==4) LineCycleCounter +=4; which was part of the end of scan line processing. I'd no idea why it was in and had just commented it as something to ask Allan about at some point! (Allan: if you're reading this, please explain!). I now see that it was a complete fluke that the Defender loop worked correctly before, but thankfully it does once more! Hopefully you can use this to help you track down where the error is :) (You mentioned you can't use your Sam at the moment). Thanks for the sample code, it's been extremely useful :-) Going back to the bit you mentioned about screen contention being applied across the whole line rather than just two thirds - how about reducing the number of lines contended to 128 (2/3 of 192), so the overall slow down over a frame is correct. Now the timing appears to be getting more accurate I think it'd be worth implementing it properly, even tho it does mean a couple more comparisons per Z80 instruction. I've also a few more questions that I hope someone can kindly help me out with: - Is mode 1 contended for all parts of every scanline, or is it still uncontended for the border strips of each line too? - For the 128 of the 384 tstates per scanline that aren't on the main screen, are 64 tstates spent in each border? or is it a little less to allow time for the beam to move back to the left of the display? (could that be what the extra 4 tstates were for?) Si ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/
RE: Defender on SimCoupe (Was: Defender Source Code)
Ian Collier wrote: Do you also ensure that the screen is black when the display is disabled? Yes, but currently only to the resolution of a single scanline. If the screen is disabled at the end of the line when it comes to draw it it'll be drawn black instead, even if it was only disabled in the right-hand border area! Some of my code relies on this for cosmetic effect - ie, cleaning up pixels which couldn't be modified in time. I think ESI's The Lyra 3 does this too. Sounds like that'll need finer control... it should still be possible by going off the LineCycleCounter value when it's been switched off, but instruction timing is going to be even more crucial! Multiple on-offs on the same line would be a bit of a pig to do too tho! There does still seems to be some mess left below the 'loading' counter from the previous screen in The Lyra 3 for some reason. I suspect it may well be easier and probably more accurate to hard-wire all the instruction times up to the nearest 4 (more accurate than the standard timings because instruction reads always occur at 4 t-state boundaries, even when the processor is running in uncontended RAM.[1]) A while ago when I was playing with instruction timings, I went through the Z80ops/edops/cbops and changed the instruction timings from the tweaked versions to the values from the Rodnay Zaks book, with the plan to round/tweak values by either wrapping each value in a macro for a compile-time change, or doing a run-time calculation. To get the apparent correct value for Defender I'm using the raw unrounded values. I've just tried using (tstates + 3) ~3 to round up to the next 4 t-states [just noticed the 8 t-state rounding formula rounding was wrong in my last message!] but the Defender loop works out the value wrong. Also, the only instructions in the loop that were not already 4 t-state rounded were the IN A,(249) and the JP NZ,nn, and manually rounding these up in z80ops.c gave another different value. I might have to look more closely to see what the LineCycleCounter value is throughout the loop, but it seems like a strange coincidence that the raw values give the correct 0xc0c0 result! Are the instruction times always going to be 4 t-state rounded? It would be interesting to see how your modified timing code copes with my second E-Tunes player (Fred 63 onwards, or from http://mnemotech.ucam.org/mnemotech.html) *gulps* Is that ETUNES63.DSK.GZ? (loads straight from the file using zlib :-)) What am I looking for where? (remember there's no sound support yet so I can't hear anything, and my SAM's back in the loft until I can get a SCART cable!). The problem there is that a lot of line interrupt routines are involved in displaying the scrolling message - in current versions of SimCoupe the processing for one line takes too long, and the code misses the following line's interrupt, so has to wait for that during the next frame. Hopefully it won't run too slow anymore, but it might run too fast ;-) I've got a menu screen that has relies on pretty critical timing for some mode 3 palette switching , and I seem to remember that it's always run a little too fast under SimCoupe. It uses line interrupts for the start of a section, but relies on small delays and instruction timing to keep in synchronised for the remaning 25 or so lines in the larger characters. I had a quick look and it doesn't look much different - I need to have a closer look at that too. The message is sixteen pixels high, so this actually causes the program to run at one sixteenth of the proper speed. Can't see a scrolly so maybe there's something else wrong! If I go for eject on that screen I just get a black screen - should I be seeing something else after that point? [1] Running from ROM or external RAM will be different, of course, but that is probably of secondary importance? Ah, I'd forgotton about those cases... Fewer things will rely on timings there, so it may well have to go on the to-do list for now! Si
Re: Defender on SimCoupe (Was: Defender Source Code)
Ian Collier wrote: Er, actually I didn't... :-) Ook, you're right... I knew I was going to make that mistake at some point! (Sorry Andrew!) How about: Ian Collier didn't write: Do you also ensure that the screen is black when the display ;-) Si
RE: Defender on SimCoupe (Was: Defender Source Code)
David Laundon wrote (oh yes he did): For internal ports the number of t-states used depends on when the instruction occurs. IN A,(n) and OUT (n),A takes 12 *OR* 16 t-states This is already in place, with the extra 4 t-states being added when LineCycleCounter is not a multiple of 8. I notice it's also important in getting the correct Defender value, as it doesn't work without with it commented out. and IN r,(C) and OUT (C),r takes 16 *OR* 20 t-states. These need adding, and are probably important for palette changing code that is often part of line-interrupt handlers, since as Andrew (:-)) mentioned the timing accurancy for them is pretty critical. I expect INd(R) and OTd(R) instructions will probably need similar modifications, especially as OTDR is probably the most commonly used method for setting up a palette. The number of t-states since some fixed point (beginning of the frame?) after the instruction seems to be rounded up to the nearest multiple of 8. The Defender timing stabilisation fix needed the LineCycleCounter to be resynchronised at the start of the frame, so it does seem to suggest that it's frame based. *However* :) For external ports this rounding to the nearest 8 since some fixed point doesn't seem to occur. Also, IIRC, IN A,(n) and IN r,(C) both take the same time for external ports (12 t-states). Some are obviously internal or external, but I'm not sure about all of them. Are the MIDI, floppy, printer and sound ports still classed as internal? (possibly) I'd guess that reads/writes for unhandled ports will be fast too, in which case the only ones that need slowing down will be special hardware devices. If that's true then only special hardware (that has to be emulated specially) will need the extra 4 t-states - that might just be the clock and hard disk ports for now. Does that sound about right? Well, that should keep you going for a while :) The missing additional timings are easily added, and the external special cases might not be too bad either - I'll add em over the weekend unless there are other complications! Si
Re: Defender on SimCoupe (Was: Defender Source Code)
Andrew Collier wrote: Well, there are some more specific effects in certain cases, but essentially yes, all instruction times are always rounded to at least a 4 t-state boundary. I'm still confused about why the Defender loop runs ok - maybe multiple timing errors are cancelling each other out in some strange way! I might try and work out what the value should be in theory, and add some SimCoupe logging to show what it's doing for each line etc. There's a scrolly message in the middle of the screen. However, you said that screen on/off effects only happen at line resolution; how about VMPR changes? It's the same for all video effects - the video state at the end of the scanline is assumed to have been the situation for the entire line. It'll take a good chunk more processing to be able to generate the display correctly on the fly, but it'd be nice if it was done - probably as an option, with the less accurate method for slower machines! If you watch the horizontal bars at the sides of the screen; as they shrink, they should move at 1 byte every frame. With your SimCoupe timings, does this appear to be the case? Yes - I got it to wait for a keypress between frames and can see it move in by two pixels each time. I've not seen it under the DOS version (and am in NT at the moment so I daren't try it!) to know what it used to be like. The message is sixteen pixels high, so this actually causes the program to run at one sixteenth of the proper speed. Still not seen the message itself - where is it? Could it be a video effect that's being missed by the line-resolution display generation? No, the eject button exists the program. I'd guess that you've actually returned to BASIC at that point, but all the palette entries would be set to zero... ah, phew! Si
Lost SAM mailing list messages
Are there any other Outlook users (not Outlook express) that subscribe to this list? When re-nstalling NT over the top of itself, it deleted my 200MB OUTLOOK.PST file from the Windows\Profiles branch. Fortunately I had a backup from a month before, so I've not lost everything. I'm looking to get back the messages between Friday 30th July and Friday 3rd September. The messages can be exported to a .pst file by either copying them to a sub-folder and exporting that, or using a date filter on the export. A zipped version of the .pst file shouldn't be too big hopefully! Can anyone help me with this? Si
Defender on SimCoupe (Was: Defender Source Code)
Chris Pile wrote: For those interested I have made the Defender source code available. http://homepages.enterprise.net/pegasus/defender I've only just got around to playing this - it's a superb port! I think a few of us will pay you back in beer or something :-) The difficulty is very authentic too as I've yet to get past the 2nd wave! We're you one of those people that could spend hours playing a single game?? I think I've tracked down some of the problems with it running under SimCoupe... I experienced the same running fast and slow when down to the last few landers. Seems to be to do with instruction timing, as after I added an approximate form of memory contention(*) and it seems to be fine now. I'm guessing it normally runs at 25fps, so the uncontended timings meant it could manage a frame in under 1/50th when there wasn't so much to do. Manic Miner doesn't seem to have much in the way of frame synchronisation and seemed to run too fast on SimCoupe, but the memory contention seem to bring it back to a normal speed, and even stabilise the border effect in the Cold Store! Your 'anti-emulation' code almost ran correctly because I've already implemented Ian Collier's 20us interrupt time, 17us of which it's visible on the status port. The value of IX after your timing loop was either 0xc0c0 (correct) or 0xc8c8, so it sometimes started the game ok! The fix for this was to re-align the LineCycleCounter value to the end of the line when it reached the end of the display, meaning the new frame always started with at the start of the first display line - sorta cheating but forgivable I hope! The 'fix' might also make other timing sensitive video effects a little more stable, but I've yet to try any. If only I could stop myself getting distracted by minor (but worthwhile, I suppose) details I might even get the Win32 to a releasable state. I seem to have a bad habit of chipping away at lots of bits instead of concentrating on each one and finishing them off. *sigh* Si ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/ (*) No contention when display is disabled (modes 3 and 4 only), or when outside the main 192 lines of the screen in modes 2, 3 and 4. It doesn't take into account the speed-up in the border areas of the main screen, but that doesn't affect most things and can be added in the future. Uncontended timings use the documented instruction timing, and contended timings use a rough formula of ((tstates + 7) -7) - 1 (!) to give 8 t-state rounding. It's a start anyway...
Re: Lost SAM mailing list messages
Will Easson wrote: I use Outlook 98 on a Win98 PC. That any use? Yeah, that'd be great! I'm using Outlook 2000, but the .pst file will be compatible. I'll e-mail you directly about it... (Thanks for the offer too Frode!) Currently at DeVille and Woolliscroft, Sherwood, Nottingham, UK. Moving to Ashfield House Vet Hospital, Long Eaton, Nottingham, UK. Ooo, just down the road - I'm in Wollaton :-) Si ICQ: 9769343, Homepage: http://www.obobo.demon.co.uk/
RE: SAM Downloads
Andrew Collier wrote: For some time I've been wanting to buy Chris Pile's Defender game. But I've been too nervous about Persona's current stalemate to dare send a cheque - who knows if I'd ever see it again? Back in April I was asking about buying software from Persona and Dave Ledbury said I should be fine to place an order, making the cheque payable to Mrs Mackenzie. I didn't receive the order and the cheque was never payed in AFAIK (don't they expire after about 6 months?). Hopefully Persona will be back up and running at some point so I can re-order the items (including Defender :-)), but I've been waiting for a message from David before I do anything. It's a shame that so many items are stuck until Persona's back, but I understand the sensitive situation so am prepared to wait a bit. Si
RE: SAM Downloads
Andrew Collier wrote: But I agree with Si - Defender is still quite new and I don't think it has had a chance to sell to its entire market yet. Has it ever been for sale at a Gloucester show, for example? I'm up for buying it from anyone that's offering (legally)! I can't remember what else I was interested in buying now tho. I'll have to have a look around for some reviews - I'm open to suggestions too... Si
OT: Celery, Athlon and other vegetables (was: RE: My take on the SAM Scene)
Dave L wrote: After seeing how many Abit boards are dealt with via our returns department - I wouldn't recommend this to anyone! Then you've been very unlucky - my last 4 boards have been ABit (HX-LX-BH-BP) and I've not had any problems. General review sites also speak highly of them. What sort of problems do you get with them? Just get an Athlon instead if you want a DECENT bit of power at a reasonable cost ;) And dual-550 isn't decent? Uniprocessor in Win98 is fast enough, but it flies under NT and Linux (kernel compile in under 2 mins). (Guess what I'm saving up for?!) The BP6 board and the two chips cost me £205 inc VAT, which is pretty incredible bang for buck - who needs to save up? ;-) How much are Athlons? Si
RE: Hmmm - on topic discussion again.
Dave L wrote: And since when has dual celeron processing been relevant to SAM ? er, well I can run a SimCoupe on them! It was as on-topic as your message about Celery adaptors! Now that was something that was discussed by Edwin a while ago Musta been before I rejoined the list... Si
RE: My take on the SAM Scene
Dave L wrote: The only reason for shopping around for a Celery adaptor is if u want one of the modified ones for Clocking or dual process use... I highly recommend the ABit BP6 for a ready to go dual-Slot370 motherboard - I've got 2 C366s running happily at 550 in one, with little more than a few changes in the BIOS settings. Si
RE: My take on the SAM Scene
Nick Humphries wrote: Single figure sales and no commitment to rereleasing or compilations means that these titles are not marketable anymore, so is there any good reason for not putting them onto an FTP site? It's not surprising sales are low as they're impossible to get hold of! It'd be sad to see some of them being given away when there are a few of us that are still interested in paying for them, if they could find where to buy them from. Could we build a list of known titles and where they can be bought from? Have places like Fred/Persona got full control over certain titles? Are they open for business or when are they expected to be? etc. Si
Re: SAM DEVELOPER FORUM
Colin Piggot wrote: so I have taken it apon myself to create another mailing list Is this really such a good idea? The SAM world seems thin enough as it is without spreading it out over two mailing lists. The discussion on this list isn't always on-topic, but it's not as though hundreds of messages a day come through on it - the off-topic chit-chat actually seems to help keep the list alive! This is a MODERATED mailing list for the needs of Sam Users and Developers alike. To subscribe, see my webpage at http://www.quazar.clara.net/forum/ for information. The web page also says: This list is for REAL people who use REAL Sam computers and No emulation. As stated above this is for users of real Sams. So, does this also exclude REAL users who develop REAL SAM software on the emulator? Since this REAL software can also be run on a REAL SAM and would benefit other REAL users. Are you discriminating against emulation because you feel it's a threat to the Quazar (like Dave L does with the hardware he's involved with) and/or it can't be used with the emulator? Good luck with your new list - I'm afraid I won't be joining you tho. ++---+ | COLIN PIGGOT | __ ___ __ | | [EMAIL PROTECTED] |/| | | | | / | | |\ | || / | | | |__| / |__| |_\ | | QUAZAR: Hardware and | /_\| |__| | | /__ | | | \ | | Software for the Sam | | ++---+ Your new list may allow large sigs, but I believe this one has a limit of 4 lines ;-) Si
Re: SAM disk formats (was: SimCoupe 0.783a - ZIP)
On Tue, Jul 13, 1999 at 07:34:01PM -0700, Simon Cooke wrote: The current format has no concept of sector addressing, it doesn't know about different length sectors. Ian Collier then wrote: I was under the impression that the format used for Amstrad disks could do that. Bickbow. Then again, we might have had this conversation already. What he says is still true in that the current format (DSK) has no concept of sector addressing. SimCoupe does _need_ an additional format of some sort to be able to describe every possibly physical disk that works on a real SAM. I never did track down a definitive spec for the Amstrad format(s) (anyone know where I can find it?). I got to the stage where I was looking through source code to try and work it out, and only found out that it stored status values for certain actions, which is something I do too. If the format is sufficient to cover the SAM floppy controller (as there are things that can be done on the Amstrad that aren't possible on the SAM, and possible vice versa) then I'd agree that it's best to use that. The new format is certainly not set in stone as nobody else has a version that uses it, and only Aley has seen a/the proposed format described, so far. I have a few disks (Lemmings, Prince of Persia, ...) in that format that I use to play them, but they can easily be converted if the format is changed. Si
RE: SAM disk formats (was: SimCoupe 0.783a - ZIP)
Ian Collier wrote: http://andercheran.aiind.upv.es/~amstrad/File_Formats/ Ah, thanks! Now I've seen it I'm not so sure... It's pretty close but I'm not sure it's quite there either... The Amstrad controller seems to have 2 status registers for each data read command, but the SAM only has one for the actual data read. The SAM also has a status value returned as part of the READ_ADDRESS command, and I'm not sure that it's equivalent to the other Amstrad status value. The SAM READ_ADDRESS command can be used without ever having to use a READ_SECTORX command so the status value needs to be kept separate. In fact, it's possible to have a sector with a CRC error in the ID field header, which is distinct from a CRC error in the data block, so it's something that needs to be preserved. The extended Amstrad format also copes with copy protected software specifying 8K sectors, which is a clever hack since a track is only about 6K long. I'm not sure the SAM motor can be switched off on demand to be able to manage to create it (anyone tried?), but it'd be another consideration for the format needed. The extended format is also a lot more compact and gets rid of a lot of the unnecessary baggage that's in the original format for legacy support. So, if the 2 Amstrad status values are equivalent to the SAM's READ_ADDRESS and READ_SECTORX values we should be able to use the same format. If the 8K sector hack is possible on the SAM we need the extended format to be able to cover that possibility too (if it _is_ possible and SimCoupe can't handle it then someone's bound to use it!). Si
RE: SimCoupe 0.783a
Aley Keprt wrote: Si Owen still haven't released anything, so here is anothrer DOS version. That's because Si Owen has only just returned from holiday - I've not even had a chance to catch up on the SAM users list yet! snip since we must discuss the fileformat at first. (I don't want to make my own standards as Si does.) Then how do you explain the following in SimCoupe's fdi.h: #define SAD_FORMAT_ID Aley's disk backup The only thing I've added is a disk format that can describe any type of SAM disk, regular or protected, as none of the existing disk formats can handle that. .SAD disks are only .DSK files with a small header than nobody seems to use anyway, but the new images are designed to be flexible enough for any disk format possible on a regular SAM disk. What's so bad about that? Si
RE: ANNOUNCEMENT 2
David L wrote: The updated Persona Web site - as designed by the talented Gordon Wallis - is now up at www.persona.clara.net Does that mean Persona's back open for business too? Si
RE: Linux vs. Win32 SimCoupe - must I fight?
Thomas Harte wrote: So you can see how it looks, yeah? You'll notice how 'doesn't want' is also future tense? Actually it's present tense, but that's beside the point - the point is that I didn't say it in the first place! I can understand how it might have looked, but trying to start a witch-hunt on hear-say isn't such a good idea. Si
RE: Z80 Assembler update
I don't understand whether this Z80 will be for Sam or PC. It looks like Java app., this would be much better. It's for the PC, but it'll make it much easier to develop code for the SAM :-) Does it support clever macros? Knowing Simon, it'll support everything you'll ever need! Si
RE: The win32 SIM Coupe
Alex Keprt wrote: Since it is noncommercial product, people doing Win32 version probably won't have sufficient resources (time, ability, ...) to do anything with Linux. I've not had time to touch the Win32 version in about 5 weeks, and am tied up for another few weeks yet :-/ I hope to get stuck into it after that and finally get a version ready to people to use. Time is the main problem will most things, as most of us have full time jobs! There's certainly plenty of ability around to get a Linux version done, it's just the time problem again... Si
Persona
Has anyone had any dealings with Persona in the last couple of months? I ordered some software 6 weeks ago and still haven't received anything. I've also tried mailing [EMAIL PROTECTED], but haven't heard anything back from there either. Si
RE: Help with : Writing my first (decent) SAM program . . .
David L wrote: If you've got a PC - the easiest solution is to get a PC TV card and use the REAL machine via the PC monitor... assuming you've got a PC that is ;) Is your picture clear enough? I borrowed a Haupage TV card but couldn't get a decent picture, as tho the signal wasn't strong enough. It was when I was fiddling with the controls in my PSU that I broke something, which is why my normal TV picture is streaky and blurred now! The normal TV picture was great on it... btw Dave, any idea what's happened to my Persona order? It's been about a month and I've still not heard a thing! Si
RE: Putting the whole boring argumet simply
Simon Cooke wrote: Actually, the plan is to go through the Windows Multimedia subsystem, as it's easy to set up and splat stuff through, and that way you also get accurate timers so we can sync SimCoupe to 50Hz :) but, but, it's been optionally synced to 50Hz for about 2 months now! But basically, it'll be stereo, 16-bit PCM output. All you'll need is a Windows driver for your sound card. Should be an easy port to the Mac too -- fingers crossed. Hopefully the rest of it will be too... Si
RE: Sam Juggler (Re: SimCoupe protected disks)
Andrew Collier wrote: MNEMOdemo1 part 2 (my bit) crashes. I never did manage to work out exactly why, but I rather suspect it has to do with interrupt timings. I've corrected the interrupt timings (as discovered Ian or yourself) so the interrupt bits aren't visible during the last 3us of the interrupt, but they stay active so interrupts can still occur. I've not tried that demo yet so I'm not sure if that's related to the problem, but it can't do any harm! Also, according to the website, SamDice crashes on startup, Fixed - turned out to be the missing 'read address' implementation in the floppy controller. 'read track' was also needed for the 'diagnostic read' to work without crashing. I extended this to add full support for protected disks, so Prince of Persia, Lemmings (tho I've broken the mouse support it seems), etc. now work when they're converted to the new type of disk image needed to describe them accurately. Existing DSK/SAD images can be formated, but only to the normal 10x512 sector format. The new images can be formatted to custom formats within the emulator, and can be viewed/edited with SamDice. I've written a BASIC program and some ASM to use on the real SAM to scan protected disks a side at a time and raw write it to another disk. I then use SBK to transfer them to the PC and (for the moment, until there's a utility to do it) use a binary editor to splice sections of them together. Of course it'll be up to people to generate their own SDF image files for any software they have as I won't distribute them, even if people claim to own the original! Si
RE: CLOSING ARGUEEMENT ON - SimCoupe protected disks Copyright
David L wrote: Not so tricky with a good hard drive removable rack! Indeed, I take the 2 hard disk caddies out of my machine in work every night when I go home, so I can plug them in there if I need to use them. Ironically, the last hard disk I had that died was the one fixed in the machine! Si
Re: Source of technical information
Thomas Harte wrote: (don't have a clue what mode 2 was all about though, thinking in retrospect, was it something like Spectrum style with a higher colour resolution?) Yeah, similar to the Spectrum but with an attribute byte for each data byte, and without the annoying layout! ;-) and, ummm, the size of the floppy discs! Standard format is the same as the +D: 800K, 780K available for data. All I've found online is the unfinished technical manual at nvg, is there anywhere else I can get information? I think that might be Simon Cooke's unofficial technical manual that you've seen. You really need to get hold of the original official technical manual for a description of graphics modes, keyboard, memory, sound chip, floppy drive, etc. It doesn't contain any on the mouse or clock (and other peripherals), but it's still the best SAM reference out there. Unfortunately, I'm not sure where you can a copy from now, but I'm sure someone else on the list will know. My first bet would be to try Bob Brenchley, if he's reappeared. Judging by the state and number of the only available emulator compared to the state and number of Spectrum emulators, I am assuming there is some complex voodoo going on at some point, but there you go. I guess it's just because it's not as well known as Spectrum - there were an awful lot more Spectrums than SAMs! Only one person I know has heard of the SAM, and he returned it shortly after buying it (back in '89) because he wasn't happy with it! SimCoupe is really the only serious contender as a SAM emulator at the moment, and it's still being worked on, so watch this space... I'd say it's more difficult to emulate than the Spectrum, mainly (I'd say) because a lot of the software is very timing sensitive. Things like hi-resolution colour support can be optional in a Spectrum emulator but is really a must for the SAM, or not even the startup screen will appear correctly! How does a Z80B differ to a regular Z80 anyway? And what about every other aspect of the machine? It runs at 6MHz instead of 3.5MHz (for the Spectrum), but other than that's is about the same. RAM contention eats a chunk of the 6MHz for normal SAM running. Any good online sources, or do I need to track down a copy of the original, finished, technical manual? I'd start with the techincal manual, and maybe have a browse around the SimCoupe source code to learn some additional bits and pieces. To supplement that diet you can always ask questions here too... Si
RE: New Argument about COPYING (WAS CLOSING ARGUEEMENT ON -SimCoupe protected disks Copyright )
Its just a Means to a End , If you need to BACKUP your purchase, but its protected to stop PIRACY , MODIFYING Correctly working code (the Protection ) is illegal (SECTION 50C as previously stated) :) Fortunately, backing up disks to a different media isn't modifying any code, in fact it's not even changing much about the format of the disk, it just lets us legal owners make the most of our purchase :-) Si
RE: Win32 SimCoupe
Aley Keprt wrote: I can't imagine what algos can be better than reading a one single value from a table. Especially in this case, when every table has 256 bytes, and there are some 4 or 8 tables in the Z80 emualtor. Is this too much for Celeron's cache? I don't think so. Probably not from one table, but if you start adding table lookups for other things you could push the working program size over the limit to be kept in the cache. I've not really looked into why the speed improvements I saw on my Celeron didn't make any difference on the PII, but the cache size/speed would be my first guess. The fact that my Celeron cache runs at full speed compared to the half speed PII cache means there's a nice boost when it does keep within it, and it still averages out at about PII speed even when it doesn't! It'll probably be worth looking into at some point to see if it help much... Si
RE: New Argument about COPYING (WAS CLOSING ARGUEEMENT ON - SimCoupe protected disks Copyright )
David Ledbury wrote: Some already does ;) Especially if it happens to be the Atom ;) Owners of the Atom still can't use the hard disk for existing protected titles tho - if I owned the hard disk I wouldn't be too happy about that. As usual, the protection ends up as more of a disadvantage for the legal owner, as people that want to hack/copy them will still do it anyway. SAM software disks could always be personalised with the details of the owner before being sent out, as people will be a lot less likely to distribute disks if their name and address is part of them. The Spectrum emulator Z80 does (or at least _did_) this, and sections of code are decrypted using those details to stop a simple patching job from getting around it. It wouldn't help the software already out there, but it'd be a start. Selling the software on to someone else would be interesting tho! Si
RE: CLOSING ARGUEEMENT ON - SimCoupe protected disks C
JohnnaPig Teare wrote: Everybody who has ever wanted to buy lemmings or pop has got it now surely - I wouldn't even know where to point someone t buy a copy. I've only just picked a few things up 2nd hand, as I couldn't see anywhere obvious and easy to buy them from. Last night was the first time I've seen Lemmings on the SAM - great fun! I'm just waiting for my order from Persona that includes Defender... The SAM world can only survive if we start to pool our resources and help to advance SIM Coupe ie. getting it running in WIn32 properly. My thoughts exactly, but one or more people on this list still see the emulator as a threat. (Still no nearer tofinding that Win32 version - anybody going to let me in on th esecret?) The original archive is still available as http://www.obobo.demon.co.uk/sc.zip but lacks all sorts of things that have been put in since (it's windowed only, but you can use F5 to change screen size). I've not had much time to work on it recently, and there are a few things that still need to be done before it's worth replacing the old archive. Si
RE: Sam Juggler (Re: SimCoupe protected disks)
Dave Whitmore wrote: On Fri, 16 Apr 1999 20:42:26 +0100 Sat, 17 Apr 99 00:54:05 BST, David [EMAIL PROTECTED] wrote: Defender - thank goodness! pedant He said disk protection excluded for christsakes! \pedant I think he might be referring to some HPEN synchonisation stuff mentioned a while back ; there's probably no reason why they both can't be 'fixed'. }:- 'thank goodness!' - hmmm, I can guess... Si
RE: Sam Juggler (Re: SimCoupe protected disks)
Aley Keprt wrote: Juggler seems to use standard disk format, but it doesn't work in emulator. Any idea? It's appears to be a bug in the SimCoupe floppy controller, caused by each disk side being treated as a full drive controller with its own set of registers etc. The only time the side bit of the port seems to be needed is for actual data reads and writes. Juggler steps the drive head using the I/O ports for the same side it wanted to move to (224-227 for side 0, 228-231 for side 1), but always checked the track value using the first 4 ports (side 0). So, as soon as it reached side 1 the track value it read back was always going to be stuck at 79 (the last track position on side 0), leaving Juggler in an infinite loop trying to get to the next position. It probably also explains some strange logs I've seen where SAMDOS seems do single steps that wrap the track below zero then back down to the track position needed. Is there any other stuff that doesn't work with SimCoupe? (disk protection excluded, for now) Si
RE: Sam interrupts: the sequel
Ian Collier wrote: The z80 code and a short binary follow. You can test the binary snip The binary seems munged again - could you please zip it and resend it? defs 56-p What's the 'p' part of this? I can't see a label for it, so is it something specific to your assembler? What size should the gap be? I assembled the rest of it but it hung without doing anything, so I guess it The real Sam is keeping the interrupt active for somewhere between 120 and 132 cycles. On a related note, I was looking at a repeated interrupt problem with SimCoupe last night. I had a line interrupt routine that was very short so it completed while the interrupt was still active on the status port. This caused the handler to be run for a second time before the active interrupts were cleared from the status port after the 30us (180 cycles). I added an extra variable that is reset when the interrupt is processed, leaving the status_port alone so it can be read by the interrupt handler code. I can't see that it's anything that I've broken from the original code, but that did cross my mind! I noticed this when the scroller in my PacMan was being displayed incorrectly because the 2 line interrupts I used had got out of sync. This only happened after I'd tweaked the instruction timings in the Z80 core, which must have shortened the time taken by the handler to just below the active time, so it was still active when it returned. I noticed that shortening the interrupt active time to 20us (120 cycles) seemed to fix it, as that was short enough to to the reset before the interrupt handler had returned. I'm surprised the multiple interrupt effect doesn't happen with your short interrupt handler - when I can run it I'll have a look! So, would reducing the active time to about 125 cycles, taking the actual interrupt time into consideration for the active interrupt time, and adding the flag to prevent multiple handle calls, cover it? Si
RE: SCART Solution
Justin Skists wrote: [description clipped] Cool. Thanks. I'll have a go at making one sometime! :) Bagsy I try first! ;-) Si
RE: Sam interrupts: the sequel
Stefan Drissen wrote: Obviously p is the current program counter value. 56-p will ensure that the next instruction is then assembled at address 56 I wondered about p being PC, but 56 minus PC (that is about 32797 because of my ORG 32768) didn't make any sense! I now presume that it means pad out the code (with NOPs or whatever) up to address 56 so some code can be there for an IM 1 handler. Is this the Comet assembler? Where does it default to putting the code if it assumes that PC is zero? 32768? I might have a better chance at getting it to build right under the SC_ASSEMBLER or Lerm assembler, if I can remember the directives to use (DISP in one of them I think...). If all else fails I'll pad it out manually! (also known as the address mode 1 interrupts jump to). ... and I've always thought the reset code was there! Si
RE: Sam Juggler (Re: SimCoupe protected disks)
Aley Keprt wrote: Yes, Juggler seems to use standard disk format, but it doesn't work in emulator. Any idea? Hmmm, mine gets right up to the point of showing the animation and just sits at a black screen. Is that the same as you (I presume so!). If I get time tomorrow I'll see if it's anything I can spot... Does Lyra III work in emulator? It does seem to to me, but looks like it's missing a border effect. Then again I've still not managed to transfer it back to a real floppy to use it on my SAM! Si
RE: SimCoupe interrupt timings
Ian Collier wrote: For the moment, assume that the screen is turned off or it happens to be displaying the border. At this time, all accesses to main RAM are restricted by the ASIC to occur only on every fourth cycle. (This does not apply to external RAM or to ROM). Ah, didn't suspect RAM contention for the effect - I thought that would come up further down the line tho! However, for PUSH HL I believe it goes something like this snip Can you recommend a reference for this sort of instruction detail? I'd be game to go through it at some point to try and get the rounding right to implement RAM contention... Thanks for the explanation Ian! Si
RE: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
Ian Collier wrote: It was basically a choice between keeping 8-bit quantities and shifting+ORing whenever register pairs are used, and keeping 16-bit quantities and shifting whenever single registers are used. I made the choice arbitrarily as it seemed easier to deal with the 8-bit registers individually. I was thinking of a packed structure (but not necessarily in a strcuture) so that B is stored in the the location following C, so you can pick each out individually or BC as a WORD, without needing to shift or OR anything. Picking the word out was the bit that I was thinking would be endian sensitive. It'd probably work if done as a C union, but I wasn't sure how efficient that'd compile up to be compared to the simple variable version. I might give it a try with HL to see what different it makes. Si
RE: SimCoupe interrupt timings
Ian Collier wrote: Not really - it's mostly guesswork, although I did measure a lot of instructions experimentally. I think Pedro Gimeno did something similar for the Spectrum and the results are in the cssfaq I found Pedro's work at lunch-time and it looks like a good starting point. At the weekend I might have a look at adding the delays to (normal RAM) reads and writes, just by rounding up to the next 8 t-states when I think the main display area is being read by the ASIC (not including border). The extra split timings will then need to be added for reads and writes within the various instructions - thankfully a good chunk of the instructions don't access memory! It'll take a lot to get right, but hopfully it'll allow some timing sensitive code (particularly in demos) to be closer to working as expected. Si
RE: SimCoupe protected disks
Simon Cooke wrote: I checked out... you can't do it without writing your own kernel-mode driver :) I was hoping that FLOPPY.SYS would have support for COMMAND_READ_TRACK but it doesn't, as that may be all that's needed to read any Sam disk (well, it sounds like it in theory). I'll have a go at adding it, but it's a real pain doing any work with file system kernel-mode drivers as you need to reboot after every change. I built my own version and started it manually, but the drives are not visible :-( Another option is just to modify the drive media table table to add support for disks with 10 sectors per track, and rebuild the driver with a different name and with different symbolic links so it's seen as SAMA: SAMB: etc. That should give access to 10 sectors per track for all normal format Sam disks, which would be a start anyway! Not that many people want to read/write at that low a level, it would seem... Wimps ;-) Si
RE: CLOSING ARGUEEMENT ON - SimCoupe protected disks Copyright
Simon Cooke wrote: CD's are much more durable, and as such, don't have this limitation. Doesn't the surface still oxidize over time though? (or was that just the early disks that weren't sealed so well). Even so they still last longer than floppies! Also: OIDS on the ST. Mirrorsoft went bust. No backup copy. Bugger. No Oids. Would it be legal for you to download a disk image of it from the web, as you own the original disk? Or would the person that uploaded it be breaking the law for effectively distributing it? Or if you knew someone that owned it, could you reformat your disk and make a copy of theirs? Maybe I shouldn't have started all this! ;) Si
RE: SimCoupe protected disks
Chris White wrote: Private Email me the Disk layout (What tracks are what) , just for my curiousity Coincidentally I'd just contacted Persona about buying a few software titles to play with (I've hardly got any games!) and Defender was one of them. Sounds like a good challenge for some point - it'll give me a chance to learn about SAM disk formats. }:- Perhaps reading 'real' SAM disks in emulation might be more trouble than it's worth??? I would certainly put quality sound emulation at the top of my wish list. True , but unless you can read the disk sound is usless Especially as most of the decent stuff probably comes with some sort of disk protection! Si
RE: SAM Scart
Martin Fitzpatrick wrote: anyways... if you want it lemme know... (same goes for anyone else, though justin did bagsy, and i cant ignorr the rules of the playground Better let him have first pick, or he'll only get some of his friends to come and beat it out of me! I may have a go at doing it myself - I can't imagine I can do that much damage if I get it wrong (or can I?!) ;-) Si
RE: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
Aley Keprt wrote: Well, I have used another Z80 CPU emulator in my SAA1099 player. It is not 100%, but it uses very efficient algo's for computing flags. And it is platform independent. This may help. Sounds good - I'd come across the look-up tables in another Z80 emulator and wondered about using the same thing - it'd be faster than the current comparing, ORing and shifting. Might be worth giving it a try, but making sure the table includes the weird undocumented flags that the current version does. Si
