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 version - isn't it a separate interpreter? The current UI still only consists of a single File menu containing Exit(!) but I've created a few dialogue boxes for setting things up that will be accessed through it. I'd like to use the open common dialogue box for file selection and tabbed dialogue boxes for keep the options clear. > 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 checked the latest xz80 source yesterday and the INI and OTI flags were still as SimCoupe has them. 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 (all my ASM attempts in the memory functions were worse than the optimising compiler!). Si
