PC Disk Drives (oops - forgot something!)
Oops... forgot to say that in the schematics for the external disk drive interface as well as the citizen drive circuitry, the Drive Select A/B pins on the floppy connector and left unconnected (pins 12 & 14) Do these need to be connected to something to enable the PC drive ? Colin Piggot Quazar : Hardware and Software for the Sam http://www.quazar.clara.net/sam/
Re: Simons oops
Well @ least i know my mail package is working and all my account for that matter :) C PS. It didn't work - Original Message - From: Simon Cooke <[EMAIL PROTECTED]> To: Sent: Saturday, October 09, 1999 2:16 AM Subject: Re: oops > > Take a bow, [EMAIL PROTECTED] - yes David L, that's you. > > > > Whatever you just did, take it back again. Not funny, not clever. > > > > Andrew > > I just faked an unsub message from my account as Sparticus999 to try and > remove him. we'll see if it works. > > Simon > > > > > >
Re: oops
> Take a bow, [EMAIL PROTECTED] - yes David L, that's you. > > Whatever you just did, take it back again. Not funny, not clever. > > Andrew I just faked an unsub message from my account as Sparticus999 to try and remove him. we'll see if it works. Simon
Re: oops
>And the Recieved: headers are getting longer... Received: from bftoemail24.bigfoot.com ([IPv6::::208.156.39.124]:40715 "HELO bftoemail24.bigfoot.com" ident: "NO-IDENT-SERVICE[2]") by sabre-wulf.nvg.ntnu.no with SMTP id <49352-31503>; Sat, 9 Oct 1999 01:59:26 +0200 Received: from sabre-wulf.nvg.ntnu.no ([129.241.210.67]) by bftoemail26.bigfoot.com (Bigfoot Toe Mail v1.0 with message handle 991008_195924_2_bftoemail26_smtp; Fri, 08 Oct 1999 19:59:24 -0500 for [EMAIL PROTECTED] Take a bow, [EMAIL PROTECTED] - yes David L, that's you. Whatever you just did, take it back again. Not funny, not clever. Andrew -- -- Andrew Collier ([EMAIL PROTECTED]) --My other -- http://mnemotech.ucam.org -- .sig is a -- Part 3 Materials Science, Cambridge -- PDF file --
Re: oops
On Sat, 9 Oct 1999 00:57:37 +0100 Sat, 9 Oct 99 01:01:13 BST, Andrew Collier <[EMAIL PROTECTED]> wrote: >>I said 'disc!'. People believe me, I didn't mean it. :-) > >What's going on?! Is it just me, or has everybody got about 15 copies of >this message so far? > >And the Recieved: headers are getting longer... No, it's just DL making a complete and utter prat of himself. I didn't mean to upset him, I just didn't like the way he was shouting. So he gets all upset and.. oh this is so tedious. Dave
Re: oops
>I said 'disc!'. People believe me, I didn't mean it. :-) What's going on?! Is it just me, or has everybody got about 15 copies of this message so far? And the Recieved: headers are getting longer... Andrew -- -- Andrew Collier ([EMAIL PROTECTED]) --My other -- http://mnemotech.ucam.org -- .sig is a -- Part 3 Materials Science, Cambridge -- PDF file --
oops
I said 'disc!'. People believe me, I didn't mean it. :-)
Re: oops
On Sat, 9 Oct 1999 00:57:37 +0100 Sat, 9 Oct 99 01:01:13 BST, Andrew Collier <[EMAIL PROTECTED]> wrote: >What's going on?! Is it just me, or has everybody got about 15 copies of >this message so far? > >And the Recieved: headers are getting longer... Then again, I just got two copies of this one. Some people are gonna be unpleased when they get all this crap. :-/ Dave
Re: Oops
On Mon, Aug 02, 1999 at 01:39:05PM +0100, Martin Fitzpatrick wrote: > Lemme know if you want em now/later Frode has obliged, so it matters no more. Thanks for the offer, and thanks to Frode as well. :-) imc
Re: Oops
Hi Ian, I keep copies of all the mail sent on here (you ARE being watched... ) for a while going back to 11th of January if you want em... Urm... in Netscape Communicator - so I dunno how I'll get that to you?! Lemme know if you want em now/later Martin Ian Collier wrote: > > Stupid arsing disk quotas again... I have inadvertently junked the > following messages. If anyone has them, they will come in handy for > the archive (if I ever get round to updating it, shortly before SOI is > released...). -- Email: [EMAIL PROTECTED] ICQ#: 11077801 AOL/CServeIM: Flupert
Oops
Stupid arsing disk quotas again... I have inadvertently junked the following messages. If anyone has them, they will come in handy for the archive (if I ever get round to updating it, shortly before SOI is released...). >From [EMAIL PROTECTED] Sun Aug 1 00:25:55 1999 Subject: Music >From [EMAIL PROTECTED] Sun Aug 1 08:45:50 1999 Subject: Amstrad Printer >From [EMAIL PROTECTED] Sun Aug 1 10:53:07 1999 Subject: Some SAM scans >From [EMAIL PROTECTED] Sun Aug 1 12:14:14 1999 Subject: Re: Amstrad Printer >From [EMAIL PROTECTED] Sun Aug 1 12:58:07 1999 Subject: DMP3000 >From [EMAIL PROTECTED] Sun Aug 1 13:18:20 1999 Subject: =?iso-8859-1?Q?Fw:_=5BFwd:_Sam_Coup=E9=5D?= >From [EMAIL PROTECTED] Sun Aug 1 17:06:39 1999 Subject: Re: =?iso-8859-1?Q?Fw:_=5BFwd:_Sam_Coup=E9=5D?= >From [EMAIL PROTECTED] Sun Aug 1 20:30:29 1999 (Subject line absent) >From [EMAIL PROTECTED] Sun Aug 1 20:50:58 1999 Subject: Hello >From [EMAIL PROTECTED] Sun Aug 1 21:36:53 1999 Subject: Re: Hello >From [EMAIL PROTECTED] Sun Aug 1 22:55:59 1999 Subject: Re: >From [EMAIL PROTECTED] Sun Aug 1 23:13:50 1999 Subject: Re: imc
RE: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
Aley Keprt wrote: > I can't imagine the situation, where unions are inefficient. > Go and try it and you will see. > The Z80 emulator I use in my programs use unions and it looks very > efficient. I've done it already and it didn't actually seem to make much difference to the performance from my tests. I've changed it to handle HL, IX and IY the same way now too, instead of as separate special cases in each instruction that used them, and that didn't make a whole lot of difference either from what I can see (it does neaten it up a lot tho). Si
Re: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
> On Tue, 13 Apr 1999, Si Owen wrote: > > > 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 > > I was under the (probably ill-informed) impression that C unions were > actually DEAD EFFICIENT. Maybe that efficency goes down if you try to > access individual bytes from a union of, say, two eight-bit bytes or > one sixteen-bit word (since those bytes cannot possibly be aligned to a > 32bit boundary). Try it and see, I guess. > > dave > I can't imagine the situation, where unions are inefficient. Go and try it and you will see. The Z80 emulator I use in my programs use unions and it looks very efficient. Aley [eili] Keprt - student, programmer (multimedia soft. etc.) phone: +420-68-538 70 35 e-mail: [EMAIL PROTECTED] *** http://get.to/aley
RE: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
On Tue, 13 Apr 1999, Si Owen wrote: > 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 I was under the (probably ill-informed) impression that C unions were actually DEAD EFFICIENT. Maybe that efficency goes down if you try to access individual bytes from a union of, say, two eight-bit bytes or one sixteen-bit word (since those bytes cannot possibly be aligned to a 32bit boundary). Try it and see, I guess. dave
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: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
On Wed, Apr 07, 1999 at 04:10:53PM +0100, Si Owen wrote: > Ian Collier wrote: > > Does the Amstrad DSK format not cover this? (I don't actually > > know anything about it, except that it is more complicated than > > a straight dump of all the tracks on the disk.) > I've not found any official docs for it but I've flicked through the > comments in some ASM code that reads them, and it does seem to cover things > like unformatted tracks, but I didn't see anything for non-512 byte sectors. I think there is an official doc - probably somewhere on Kev Thacker's Amstrad site. > I was wondering whether the your current core would benefit from having the > register pairs in little endian order so HL can be accessed without shifting > and ORing the two 8-bit parts, so I might give that a try at some time - it > can conditionally be compiled as big endian for the platforms that need it. I'm not sure what you are getting at here. The endianness shouldn't make any difference since memory is not involved directly (though I guess the x86 will have to use memory because it doesn't have enough registers). If you force it to go to memory then it could make the emulator slower on other architectures (this was the main problem with xzx on the sparc). 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. imc
Re: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
> >At some point I added a '-fullscreen 1' flag to the command-line options, > >but I can't remember whether the last version on the site actually has it > >(it'll be in the next one of course!). > > That flag does maximized window, not fullscreen!!! i really no idea what im talking about, but it might be because your screen is larger?... martin -- Email: [EMAIL PROTECTED] ICQ#: 11077801 AOL/CServeIM: Flupert
RE: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
Simon Cooke wrote: > PLEASE don't do it this way! For a start, the moment you load a 16-bit > driver/dll into memory, Windows 95/98 slows down by maybe 25%, if > not more, due to the added processor mode switching involved... I've quite a lot of thunking as part of my normal work, and it does take a fair hit if called frequently. We managed to get away with it for some 1284 comms by reducing the number of calls, and using bigger blocks. We'd need to call it at 50Hz for the sound which would be a big dent in performance - it'd be nice to see it working as a starting point tho. > Secondly, this probably won't work under NT. Indeed, flat thunking (32-bit to 16-bit) isn't supported, even if it will let you run it. > Thirdly... just ... ugh! :) :-) Si
RE: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
Simon Cooke wrote: > Don't forget -- the cache comes into play here a lot, so tables aren't > necessarily as efficient as you might think. PROFILE YOUR RESULTS!!! I completely agree - my Celeron only has 128K of cache but it's running at full clock speed (464MHz for my setup) giving it a nice boost. I did some tweaks that gave me an extra 20fps or so on the Celeron but that didn't make any difference on the PII. I'm relying on the copyright screen for benchmarks at the moment and watching how things affect that. Si
Re: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
From: Aley Keprt <[EMAIL PROTECTED]> > TSR? What? SAAemu is not a TSR!!! > Dear boy, wake up! TSR have gone some months ago. > You need a 32bit DLL which will call 16bit DLL which will load > the SAAemu to its DOS memory (<1MB) and call it in real mode. > This should be possible under DPMI (Win16), since it is used in SimCoupe. > Please look to SAAemu sources (in the SimCoupe 0.782a), and there you can > see how does it work in DJGPP. In Win16 it would be the same. And Win32 must > call this 16bit DLL. Ugghhh!!! Gackkk Argg! PLEASE don't do it this way! For a start, the moment you load a 16-bit driver/dll into memory, Windows 95/98 slows down by maybe 25%, if not more, due to the added processor mode switching involved... Secondly, this probably won't work under NT. Thirdly... just ... ugh! :) Simon (NSFMSFT)
Re: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
From: Si Owen <[EMAIL PROTECTED]> > 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 Don't forget -- the cache comes into play here a lot, so tables aren't necessarily as efficient as you might think. PROFILE YOUR RESULTS!!! Simon (NSFMSFT)
RE: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
Aley Keprt wrote: > That flag does maximized window, not fullscreen!!! It's actually more or less the same thing - the video mode is changed and I am drawing to the entire DirectX surface. That version doesn't disable the caption so it's still visible - if it doesn't actually maximise you can still click on windows underneath and move them around while the emulator is running (not anymore tho - I might have to release another test version to get you up to date!). > TSR? What? SAAemu is not a TSR!!! > Dear boy, wake up! TSR have gone some months ago. Oop! I still remembered it from being a TSR under DOS. ;-) > Please look to SAAemu sources (in the SimCoupe 0.782a), and there you can > see how does it work in DJGPP. In Win16 it would be the same. And > Win32 must call this 16bit DLL. Ok, I'll take a look - I'd be interested in seeing it working, even though it'll be replaced by a 32-bit version. 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
Re: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
>> btw. I've tested the current Win32 version of SimCoupe (that one I've get >> from Si Owen) and the fullscreen mode wasn't fullscreen, but just >> maximized window. > >At some point I added a '-fullscreen 1' flag to the command-line options, >but I can't remember whether the last version on the site actually has it >(it'll be in the next one of course!). That flag does maximized window, not fullscreen!!! >> Of course, the current SAAemu version 0.50 is also possible to be run in >> Windows 95, it depends only on Si Owen's skillness in including it in his >> SimCoupe for Win32. > >I'll give it a go, but I've not had to interface any Windows stuff with TSRs >before (I've done some 16-bit DLL to VxD through DPMI which might help). >It'll probably need flat thunking back to 16-bit before it'll be accesible, >so it might not be too bad. It'd probably be worth waiting and doing a >32-bit version to minimise the hacking and improve the efficiency! TSR? What? SAAemu is not a TSR!!! Dear boy, wake up! TSR have gone some months ago. You need a 32bit DLL which will call 16bit DLL which will load the SAAemu to its DOS memory (<1MB) and call it in real mode. This should be possible under DPMI (Win16), since it is used in SimCoupe. Please look to SAAemu sources (in the SimCoupe 0.782a), and there you can see how does it work in DJGPP. In Win16 it would be the same. And Win32 must call this 16bit DLL. Aley Keprt
Re: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
> > Z flag but left the other part of the expression alone. It's a great C Z80 > > emulator, and I can't see there being much else to squeeze out of it without > > going to ASM > > Actually I think I just typed in what came into my head - I'm sure some of > the flag calculations must be horribly inefficient. Then again, there is > no easy way to generate them unless you want to rely on the host cpu having > similar flags which you can just copy. > > imc 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. (it uses some really large tables and read flag values from these tables. it uses tables of at least 256 entries for each one state of the result, and the tables give fast solution for sign/zero/carry/overflow flags. i think nothing could be better than this.) Aley [eili] Keprt - student, programmer (multimedia soft. etc.) phone: +420-68-538 70 35 e-mail: [EMAIL PROTECTED] *** http://get.to/aley
RE: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
Simon Cooke wrote: > Nothing time-critical would be in Java - I mean, yeuck! - but I don't mind > having the overhead of C++ for a disk controller :) Would it need to be time critical? Wouldn't it be running in 'emulator' time anyway, so it'd only need to stay in sync with that? > Si (NSFMSFT) Hmm, wot's the abbreviation for?! Si
RE: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
Aley Keprt wrote: > I must notice, that the current SimCoupe's UI is a bit weird, and > I vote for a new Win32 interface. I hope Si Owen will make some classic Win32 stuff. I too would like it to have a nice(?) Windows front-end, so I'll see what I can do. > btw. I've tested the current Win32 version of SimCoupe (that one I've get > from Si Owen) and the fullscreen mode wasn't fullscreen, but just > maximized window. At some point I added a '-fullscreen 1' flag to the command-line options, but I can't remember whether the last version on the site actually has it (it'll be in the next one of course!). > I hope this is only alpha version. It was very alpha - don't trust anything you see in that version! > Of course, the current SAAemu version 0.50 is also possible to be run in > Windows 95, it depends only on Si Owen's skillness in including it in his > SimCoupe for Win32. I'll give it a go, but I've not had to interface any Windows stuff with TSRs before (I've done some 16-bit DLL to VxD through DPMI which might help). It'll probably need flat thunking back to 16-bit before it'll be accesible, so it might not be too bad. It'd probably be worth waiting and doing a 32-bit version to minimise the hacking and improve the efficiency! Si
RE: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
Ian Collier wrote: > There are a couple of other things I have fixed since the code was > incorporated in SimCoupe. Thanks for those, I've made the changes here! Si
RE: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
Ian Collier wrote: > Does the Amstrad DSK format not cover this? (I don't actually > know anything about it, except that it is more complicated than > a straight dump of all the tracks on the disk.) I've not found any official docs for it but I've flicked through the comments in some ASM code that reads them, and it does seem to cover things like unformatted tracks, but I didn't see anything for non-512 byte sectors. I'll have a more thorough look for the format sometime. I'm not really up enough on snazzy disk protection methods to understand what's needed as I never bothered with them myself, so I'll have to have a play with some real disk. Can anyone recommend any demos or games that have use fairly non-standard disk formats? > Actually I think I just typed in what came into my head - I'm sure some of > the flag calculations must be horribly inefficient. Then again, there is > no easy way to generate them unless you want to rely on the host > cpu having similar flags which you can just copy. I think there's at least one emulator that gets quite a speed boost from doing just that. Unfortunately most ASM Z80 emulators can't cope with the paged SAM memory layout without having to copy up to 32K around when the paging ports are written to (which would probably be too slow if it was frequent, even copying as QWORDs!). They do direct memory accesses on a fixed 64K address range, which bypasses common (but slower) memory read and write routines. I was wondering whether the your current core would benefit from having the register pairs in little endian order so HL can be accessed without shifting and ORing the two 8-bit parts, so I might give that a try at some time - it can conditionally be compiled as big endian for the platforms that need it. I might experiment to see if anything else can be trimmed down, but I think the video generation eats so much (especially when large portions of the screen change frequently) that it's not worth spending too much time on it! Si
Re: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
On Tue, Apr 06, 1999 at 04:15:16PM +0100, Si Owen wrote: > In the floppy driver I've added the direction flag and write protection, and > tighened up some of the flags used. I'm playing with the idea of yet another > disk format capable of handling custom disk formats used by some of the > commercial software (and possibly demos?) Does the Amstrad DSK format not cover this? (I don't actually know anything about it, except that it is more complicated than a straight dump of all the tracks on the disk.) > I checked the latest xz80 source yesterday and the INI and OTI flags were > still as SimCoupe has them. SimCoupe has probably changed more recently than xz80 has. ;-) > I just changed the 'b>0' to '!b' to correct the > Z flag but left the other part of the expression alone. It's a great C Z80 > emulator, and I can't see there being much else to squeeze out of it without > going to ASM Actually I think I just typed in what came into my head - I'm sure some of the flag calculations must be horribly inefficient. Then again, there is no easy way to generate them unless you want to rely on the host cpu having similar flags which you can just copy. imc
Re: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
On Tue, Apr 06, 1999 at 01:36:04PM +0100, Allan Skillman wrote: > On the subject of the undocumented flag behavior, the commented out code > comes from the Z80 kernel in Xzx which was the original kernel used for > the early versions of SimCoupe. I wonder where Ian got his info from, > most of the stuff in xz80 is pretty spot on, Ian? I wonder, too... must have had a brainstorm. :-) You will remember I used to have the "dec b" and the "out" in the wrong order too. All the weird and wonderful undocumented flag behaviour is apparently written up in the cssfaq, although I am not online at the moment to check. My guess at the parity flag for the INI instruction is nowhere near what is written there. As for the difference in zero flag between INI and OUTI, I can only assume that it is wrong since such weird behaviour (at variance with published docs) ought to have merited a comment in the code if it were intentional. There are a couple of other things I have fixed since the code was incorporated in SimCoupe. cbops.c -#define bit(n,x) (f=(f&1)|((x&(1<>8)|(((a&0x0f)<(z&0x0f))<<4)|\ + f=(y&0x80)|(z&0x28)|(y>>8)|(((a&0x0f)<(z&0x0f))<<4)|\ (((a^z)&0x80&(y^a))>>5)|2|((!y)<<6);\ } while(0) (Fix for the undocumented flags in the CP instruction.) imc
Re: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
>Hi All, > >Before I go on, I would just like to say thanks to Si for taking on >SimCoupe for Win32. Its someting that has been required for quite a while >now, and I have neither the expertise in Win32 nor the time (anymore) to >take it under my wing, and I pray for the day I can bury the DOS version :). >BTW Si, would it be possible for you to keep me up to date with the core >changes to the emulator, so I can update the UNIX version accordingly. In >fact any chance you could use Tcl/Tk for the interface so we can have a >single UI? > I must notice, that the current SimCoupe's UI is a bit weird, and I vote for a new Win32 interface. I hope Si Owen will make some classic Win32 stuff. btw. I've tested the current Win32 version of SimCoupe (that one I've get from Si Owen) and the fullscreen mode wasn't fullscreen, but just maximized window. I hope this is only alpha version. I don't know if Win32 SimCoupe is available for public, but I can promise the SAAemu for Windows 95 will be available in some weeks. Of course, the current SAAemu version 0.50 is also possible to be run in Windows 95, it depends only on Si Owen's skillness in including it in his SimCoupe for Win32.
Re: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
From: Si Owen <[EMAIL PROTECTED]> > In the floppy driver I've added the direction flag and write protection, and > tighened up some of the flags used. I'm playing with the idea of yet another > disk format capable of handling custom disk formats used by some of the > commercial software (and possibly demos?), but that'll have to be once most > other things are done (and if I get a replacement PSU so I can play with > things on a real SAM). I'm not so worried about getting the timings right or > performing proper stepped seeks (yet) - I think Simon Cooke is still working > on a (Java) VL1772-02 emulator that may do all of this better anyway! Er... actually, it's written in C++; the only thing I was thinking of using Java (or rather, WFC) for was to create a front-end shell, that would host the UI for keyboard redefinition, settings, etc etc. It'd also act as a host for the HWND of the display, when not in full screen mode. Nothing time-critical would be in Java - I mean, yeuck! - but I don't mind having the overhead of C++ for a disk controller :) Si (NSFMSFT)
Re: Win32 SimCoupe (was: Z80 flags for INI(R) and OTI(R)? #2 (oops!))
Hi Allan, > Before I go on, I would just like to say thanks to Si for taking on > SimCoupe for Win32. Hope you don't mind if I pick your brains from time to time :-) I'm working to get most of the original functionality up and running under Win32 before letting anyone at it. Even then it'll still lack sound so that'd be one of the first things for someone to add! > BTW Si, would it be possible for you to keep me up to date with the core > changes to the emulator, so I can update the UNIX version accordingly. Sure, although I'm not sure how much of a struggle it'll be keeping the sources the same. The Win32 graphics stuff is already in C++ template classes making is easier to manage, especially with virtual functions replacing the function pointers). I wasn't sure whether I could rely on the various Unix systems having a C++ compiler in addition to a C compiler. That thought brought me round to the idea of keeping the sources separate as it'd be much easier to work on. Hopefully most changes will be simple tweaks or new chunks of code that could be ported back to the Unix version as needed. A lot of the initial stuff I worked on was Win32 specific to implement functionality that's already in the DOS and Unix versions. A general run-down (probably with bits I've forgotton) is: The graphics side has taken quite a while to optimise further, and to make the most of extra video memory and hardware acceleration, if available. There are 1x1, 2x1 and 2x2 source modes for the image created - 2x1 will be faster than 2x2 if the hardware is up to it, and allows mode 3 to be displayed properly. The displayed image can be full screen (any depth) or windowed (uses the current display depth of course), and the windowed version can be stretched to any size you like (but with the aspect ratio forced to be correct). There's an optional frame sync (which uses multimedia timer to signal, instead of the tight loop checking the high resolution timer in the first version). There's also manual frame skipping options for slower machines. I've still not added 24-bit support since it can't use the template class because there's no built-in 3 byte type, and dynamic windowed to full screen switching is still away on vacation (but not really that hard to do). Other things on the ToDo list are screen off support (easy) and the CPU speedup it gives (hmmm... not to mention the mode 1 and mode 2 CPU slowdown!). Keyboard support still uses the Win32 API for a full scan but might be moved over to DirectInput if the functions are supported by DirectX3 (to keep NT support). Mouse support is already in and I've made a start on the DirectInput joystick side. I've added SAMBUS clock (read/write) and DALLAS clock (read only - still not sure if it can be written to) support. Both were done without docs so I can't be completely sure whether it'll worth with 100% of programs, but I think I've made it general enough so they should do! In the floppy driver I've added the direction flag and write protection, and tighened up some of the flags used. I'm playing with the idea of yet another disk format capable of handling custom disk formats used by some of the commercial software (and possibly demos?), but that'll have to be once most other things are done (and if I get a replacement PSU so I can play with things on a real SAM). I'm not so worried about getting the timings right or performing proper stepped seeks (yet) - I think Simon Cooke is still working on a (Java) VL1772-02 emulator that may do all of this better anyway! I'm currenly working on adding ATOM hard disk interface support, and have managed to make some progress. Unfortunately I have no real documentation to work from (except the ATA specs for the hard disk part of it) so it's all blind and progress is very slow - I wonder if Edwin will help out here? I spent a good chunk of the Easter weekend reverse engineering BDOS to see what it's doing, and have found 3 of the SAM I/O ports used and most of what they're used for. BDOS now recognises my virtual disk and displays the correct description and geometry when it boots. Strangely it won't let me select records until I use the formatter program on them (even thought I ignore writes and always return blocks of zeros for reads!). Sector reads and rights should go in tonight if I get time. Other than that I've not changed very much common core stuff, only tweaks for speed-ups and others to keep related code together (I've moved some of the graphics logic from processor.c into the new graphics classes). I've also cached a few values that are masked and checked frequently but not changed often (like border colour), and delayed the mouse reset until it's next read (and if the necessary time has elapsed) - since this is checked for every iteration of the main loop normally! > In fact any chance you could use Tcl/Tk for the interface so we can have > a single UI? I know of it but have never used it. How would it fit into the Win32 versio
RE: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
Hi All, Before I go on, I would just like to say thanks to Si for taking on SimCoupe for Win32. Its someting that has been required for quite a while now, and I have neither the expertise in Win32 nor the time (anymore) to take it under my wing, and I pray for the day I can bury the DOS version :). BTW Si, would it be possible for you to keep me up to date with the core changes to the emulator, so I can update the UNIX version accordingly. In fact any chance you could use Tcl/Tk for the interface so we can have a single UI? On the subject of the undocumented flag behavior, the commented out code comes from the Z80 kernel in Xzx which was the original kernel used for the early versions of SimCoupe. I wonder where Ian got his info from, most of the stuff in xz80 is pretty spot on, Ian? regards Allan +--+---+ | Allan Skillman | "There are five flavours of resons, the | | EDA Group| elementary particles of magic : up, down, | | ARM | sideways, sex-appeal and peppermint." | | [EMAIL PROTECTED] | - Terry Pratchett (Lords and Ladies) | +--+---+
RE: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
Frode Tenneboe wrote: > Are there any _official_ docs? :) hehe, good point! Simon Cooke will probably have them if they do exist anywhere! I usually trust the Rodnay Zaks book for the documented side of things, but can't find it anywhere. I reckon my wife tidied it out of the bookcase because it looks too shabby, so I'll have to buy another copy! > From memory: > > Z = 1 if B = 0, else Z = 0. Yeah, that's what I reckon it should be. Si
Re: Z80 flags for INI(R) and OTI(R)? #2 (oops!)
> Hi, > > The xz80 Z80 core (as used by SimCoupe) seems to set the zero flag when B is > non zero after INI and OTI instruction and reset it when B is zero. SimCoupe > has inherited the same behaviour, but I've noticed a commented out section > of code that seems to do what I'd expect. I seem to have lost my Programming > the Z80 book so I can't check it. > > I found a web site I found detailing them the flags that says the zero flag > is indeterminate, yet BDOS relies on the zero flag matching B to do block > reads from the hard disk, and it must work on a real SAM. > > Can anyone confirm what the official docs say? Are there any _official_ docs? :) From memory: Z = 1 if B = 0, else Z = 0. -Frode
Z80 flags for INI(R) and OTI(R)? #2 (oops!)
(sorry, hit ctrl-return too soon and sent it!) Hi, The xz80 Z80 core (as used by SimCoupe) seems to set the zero flag when B is non zero after INI and OTI instruction and reset it when B is zero. SimCoupe has inherited the same behaviour, but I've noticed a commented out section of code that seems to do what I'd expect. I seem to have lost my Programming the Z80 book so I can't check it. I found a web site I found detailing them the flags that says the zero flag is indeterminate, yet BDOS relies on the zero flag matching B to do block reads from the hard disk, and it must work on a real SAM. Can anyone confirm what the official docs say? Thanks Si
