Articles tagged “Cogwheel”
Loading BASIC programs from cassette tape to the Sega Master System
After I posted about the pattern filling modes on Twitter I was alerted to the BBC Micro Bot website which hosts a gallery of programs that produce impressive graphical output from very short BASIC programs (short enough to fit in a Tweet!)
I tried a few of them out but unfortunately ran into problems with a lot of them that use various tricks to reduce the original program text length by embedding non-ASCII characters directly into the body of the program. My usual approach to prepare programs was either to copy and paste them into an emulator (my emulator strips out non-ASCII characters on pasting, as these can't be mapped to keystrokes) or to save them to a file and transfer that serially, and my own editor's tokeniser and BBC BASIC for Windows both had a habit of mangling the non-ASCII characters.
Better drawing, editing, memory and emulation for BBC BASIC on the Sega Master System
I have continued to work on the Sega Master System version of BBC BASIC, and it's feeling much more like a practical version of BASIC than something that was just holding together to run one specific program! One of the key improvements is to standardise the handling of the different graphics modes. Previously I was using a coordinate system where (0,0) is in the top left corner and all drawing operations were carried out using physical device coordinates (so the screen was treated as being 256 pixels wide and 192 pixels tall).
BBC BASIC Cogwheel Electronics Emulation Sega Sega Master System Z80
Cogwheel 1.0.3.0 beta 3
I managed to break save states in the last build of Cogwheel (attempting to load a save state would fail, not being able to set a property). I've marked the offending read-only property with [StateNotSaved] and made the loader slightly more robust in Cogwheel 1.0.3.0 beta 3. It's beta 3, not 2, because I uploaded 2 and then noticed another issue - you couldn't change the controller mappings! This is something that must have been broken for ages, but either nobody noticed or they just didn't care to report it.
Cogwheel 1.0.3.0 beta 1
I've released a beta version of Cogwheel 1.0.3.0 in the hope of getting some feedback. My main concern is with the new 3D glasses code, so I'd be very grateful if you could install the emulator and run this ROM in it. The ROM simply alternates between showing a red screen for the left eye and a cyan one for the right eye (the emulator defaults to only showing the left eye, so you'll just see red for the moment). If you select a different 3D glasses mode (Options, 3D glasses, Row interleaved) you should end up with something like this:
If you drag the around the desktop the lines should appear fixed on the spot (as long as you drag it slowly enough to allow it to repaint), and if you resize it the entire form should always be covered in lines one pixel apart.
New 3D renderer in Cogwheel
I have written a new 3D-compatible renderer for Cogwheel. It holds two textures, one for each eye, and uses one of a number of different effect file techniques to mix the two views. Based on the interlacing work from the previous entry, the first technique is one that uses interleaved rows. I'm not really sure if there's a good way to convert texture coordinates into device coordinates, so am passing in the viewport height as a parameter and hoping that floating point errors don't trip me up (they haven't, yet).
C# emu2413
This is fairly embarrassing; somebody sent me an email that was flagged as spam which I accidentally deleted. So if you sent me an email and I haven't replied, I'm not deliberately being rude; could you send it again? After encountering strange crashes (not .NET exceptions, full out crashes) with emu2413 I decided to port it to straight C# instead from its existing C incarnation (emu2413.h.cs and emu2413.c.cs). Even though the original was macro-heavy it was relatively simple to port, and so there's no dependency on an unmanaged DLL to generate FM sound any more.
Controller input updates to Cogwheel
I hope you all had a good Christmas and New Year period! I received an Xbox 360 controller for Christmas, so have done a bit of work on Cogwheel to add support for it. (You can download a copy of the latest version 1.0.2.0 with SlimDX here). The first issue to deal with was the D-pad on the Xbox 360 controller. When treated as a conventional joystick or DirectInput device the D-pad state is returned via the point-of-view (POV) hat. The joystick input source class couldn't raise events generated by the POV hat so support for that had to be added.
Comments BBC BASIC C# Cogwheel Sega Sega Master System TI-83+
Sega Master System emulation in Silverlight
I've had to quickly learn Silverlight for work recently, which has been an interesting experience. I've had to write new code, which is fine but doesn't really excite me as far as Silverlight is concerned - it doesn't really matter which language new code is developed in, as long as it gets the job done. What does interest me more is that Silverlight is ".NET in your browser", and I'm a big fan of .NET technology with a handful of .NET-based projects under my belt. Silverlight therefore gives me the opportunity to run these projects within the browser, which is a fun idea.
SC-3000 keyboard and a final release
The latest addition to Cogwheel is SC-3000 keyboard emulation. The SC-3000 was a home computer with similar hardware to the SG-1000 console, with the main addition of a keyboard. Software cartridges could add, for example, BASIC programming capabilities. Due to lack of time and motivation, and the fact that the emulator is pretty much as good as I'm going to get it at this moment in time, I've removed the beta label and uploaded the latest version to its website.
3D glasses and CPU cycle counting
I reintroduced joystick support to the emulator front-end over the weekend, using a much more sensible input manager. The control editor form uses the same interface design for keyboard and joysticks - you click the button you wish to edit, it appears pressed, you press the key (or joystick button) you wish to bind to it and it pops back out again. It'll also check to see if you've moved the joystick in a particular direction on any of its reported axes. Another feature I added was better support for games that used the 3D glasses, using a simple red-cyan anaglyph output blender.
ColecoVision and TMS9918 Multicolor
One notable gap in my TMS9918 (video) emulation was its "Multicolor" mode. This mode broke the screen down into 4×4 pixel squares, resulting in a 64×48 grid. Each cell could be assigned a unique colour, giving you a crude bitmapped video mode. No Master System or SG-1000 software used this mode to my knowledge, which reduced the likelihood of it being supported at all (if I could't test it, how could I emulate it?) I was tipped off that some ColecoVision software made use of it, so set about emulating the ColecoVision.
SaveStates and Key Names
It's a good feeling when issue 1 is finally marked as Fixed - in this case it was another interrupt-related bug. The IFF1 flag was being used to mask non-maskable interrupts; I don't think it should and it hasn't seem to have broken anything just yet by making non-maskable interrupts truly non-maskable. Go! Dizzy Go! I have also changed the savestate format to something that will be a little more backwards compatible rather than a plain BinaryFormatter dump of the entire emulator state. The data is now saved in what is basically an INI file with C#-style attributes and CSS-style url() syntax for binary data.
Fun with IThumbnailProvider
Note: I have been informed that the code below no longer works in Windows 7 due to changes in the way IThumbnailProvider operates. It is recommended that you use unmanaged code instead of the managed solution presented below. I have started releasing Cogwheel binaries on its project page, so if you'd like a look at the project but can't be bothered to check out and build the source yourself you can now give it a whirl. One of the newer additions is a savestate mechanism; this is a very lazy bit of code on my behalf as all it does currently is serialise the entire emulator to a file using the BinaryFormatter.
Sound, at long last.
I have finally got around to adding sound to Cogwheel using Ianier Munoz's waveOut API wrapper. The technique used is fairly simple. I start with a sound buffer that is a multiple a number of video frames in length (1/60th of a second is one frame) - four seems a good number. This buffer needs to be periodically topped up with sound samples (every four frames in the above example). I run the emulator for one frame, then generate a frame's worth of audio. I add these samples to a queue. The sound callback then periodically dequeues these samples and appends them to its buffer.
Joysticks and Game Genie codes
The biggest update to the emulator relates to input. I've added a new control panel that lets you customise key bindings. For the keyboard, you simply click on the button you wish to customise, then press the key on your keyboard you wish to bind. As you can probably tell from the screenshot, I've also added joystick support (via the Multimedia Joystick Functions with a bit of P/Invoke for ease) which means that with a simple adapter and a free driver you can use original SMS pads with the emulator.
Cogwheel on Google Code
On bakery2k1's suggestion, I took a look at my sprite collision flag code. It only checked for collisions between sprites appearing in the foreground - sprites that were hidden behind a background tile weren't checked, which caused the Fantastic Dizzy bug. I have decided to give Google's free project hosting a whirl. As usual, they can't get it working in Opera (no big surprises there) and it's horrifically slow, but I can't really complain given that it's free, and the issue tracking is pretty handy.
/INTerminable Interrupt Problems
World Class Leaderboard Golf Well, I've just about got it the way it was before with the new interrupt code; most games work again, but the few that have always given problems (such as Desert Speedtrap) still don't work properly. I think this is the stage where I have to start trawling through disassemblies to try and work out why they're not working. Cosmic Spacehead - one of the few games to use the 256×224 mode. One problem I still haven't got to the bottom of is with the Dizzy games. They either reset when starting a new game or lock up.
Interrupts: A Fresh Start
I gave in and rewrote all of the Z80's interrupt emulation from scratch, finding some rather horrible bugs in the existing implementation as I went. Some of the highlights included non-maskable interrupts ignoring the state of the IFF1 flag (this flag is automatically cleared when an interrupt is serviced, and is used to prevent the interrupt handler from being called again before it has finished) and the RETN instruction not copying the state of the IFF2 flag back to IFF1. When non-maskable interrupts are serviced, the state of IFF1 is copied to IFF2 before it gets cleared, the idea being that if you use RETN interrupts are automatically re-enabled on exit of the NMI ISR.
Loading ROMs
OutRun Europa I've been adding a series of new features to Cogwheel. I wrote a basic zip file class a while back (only supporting store and deflate compression - the majority of zip files use deflate), and have added a Utility namespace with methods for help with loading ROMs. For example, there is a method that is passed a filename by reference, and it'll return an array of bytes of the loaded file. If the passed filename was a zip file, by any chance, it'll search for ROMs inside the zip, and modify the filename (so it might end up as C:\Path\SomeFile.zip\Game.sms).
Game Gear LCD Scaling
The Game Gear's hardware is very similar indeed to the Master System's - so similar that you can play Master System games on a Game Gear via a special adapter. Some Game Gear games were just the Master System ROMs in a Game Gear cartridge. That said, the Game Gear's LCD is only 160×144, and the Master System has a resolution of 256×192 (or 256×224 or 256×240, but those modes were very rarely used). In Game Gear mode, this resolution is simply cropped. In Master System mode something more interesting has to be done to scale this down to fit the LCD.
Necromancy
After seeing Scet and Drilian's work on their respective emulator projects I decided I needed to do something with the stagnating Cogwheel source on my hard disk drive. The only ROM I have tested where I can't find an explanation for a bug is the Game Gear Garfield: Caught in the Act game. Like many games, when left at the title screen it'll run a demo loop of the game in action. At one point Garfield would walk to the left of the screen, jump over a totem pole, shunt it to the right and use it as a way to jump out of a pit.
Parallel-Port SMS Control Pad
I've been wanting to attach an SMS control pad to my PC (and be able to use it to play games with) for a while, so put in an order from those excellent chaps at Rapid for the parts needed. The joypad (as I've now learned from disassembly) is very primitive - 6 normally-open switches, each connected between a pin on the DE-9 connector and ground. The accepted layout adapter uses the 25-pin parallel port, connecting ground to pin 18, power to pin 1 (not that the control pad uses this pin) and 7 further connections from D0 to D6 for the buttons.
Sega BASIC
I have returned to the MDI view for this project which makes life easier when it comes to putting in debugging tools. For the moment all there is is a palette and tile viewer, but I hope to add some helpful utilities - and work out a way to tie the new Brass and an emulator together for debugging assembly programs. I've extended the SG-1000 emulation some way towards the SC-3000 (Sega Game 1000 vs. Sega Computer 3000) which has mainly involved adding keyboard emulation. The result is the ability to run Sega BASIC, and so you get the obligatory program that everyone writes sooner or later...
SG-1000
I've added some support for the SG-1000, Sega's first? home video game console. The Master System's VDP is a modified TMS9918, and so most Master System games run in its extended 'Mode 4' setting. That was the only video mode, therefore, that I'd emulated in any form. For some reason, the older computer games are, the more charm they seem to have to me (maybe because the first games I played would have been on a BBC Micro, which certainly looked a lot more primitive than the Master System games I've been attempting to emulate thus far).
VDP Interrupts
The VDP can generate two different types of CPU interrupt. The first, and easiest, is the frame interrupt, which is requested when an entire frame has been generated. This is requested, therefore, at a regular 60Hz in NTSC regions and 50Hz in PAL regions - it's a useful timer to synchronise your game to. The second, and more complex, is the line interrupt. This interrupt is requested when a user-definable number of scanlines have been displayed. An internal counter is decremented each active line (and one more just after), and when it overflows it resets to the value held in a VDP register and requests the interrupt (so 0 would request an interrupt every line, 1 every other line and so on).
Real 3D on classic 2D hardware
My existing implementation of the standard mapper used the values $1FFC..$1FFF in RAM as the paging registers. This is incorrect; from what I can now tell the paging registers are only updated if you write to the $FFFC..$FFFF range, and isn't anything to do with the RAM anyway (the fact that they end up in RAM is a side-effect, not the main way of doing things). Updating my code to handle this, rather than using the values in RAM, fixed some games; notably Phantasy Star and Space Harrier. Thanks to Maxim's post, I fixed the Codemasters mapping for the Excellent Dizzy Collection:
A fun bit of hardware is the 3D glasses.
Turning Japanese
The Z80 CPU uses 16-bit addressing, which limits it to a 64KB address space. As well as fitting the program ROM into this space, we need to fit in the machine's 8KB RAM, limiting us even further. To get around this limitation, the memory is broken down into a series of windows ("frames"), and you can change what is visible in some of these windows. The memory range $C000..$DFFF can be used to address the 8KB RAM. This is mirrored from $E000..$FFFF; that is, reads and writes to $E000 work as if you were reading and writing to $C000.
Kids, just say No to bilinear filtering
The old layout of the emulator was a bit of a mess. The Z80 emulator needed to sit inside a class of your design that inherited from IHardwareController (and so exposed methods to handle hardware devices) and another that inherited from IMemoryDevice that exposed methods that could be used to read and write to memory. As you might imagine, this got a little messy what with the various nested classes needing to pass references to eachother around. The new design is much more straightforwards - you build a class that inherits from Z80A (which is the basic Z80 emulator) and override the four functions for reading from/writing to memory addresses/hardware ports.
New Z80 emulator
One chap I cannot thank enough is CoBB for all his hard work in the Z80 field. I've rewritten the Z80 emulation from scratch; this time it uses an expanded switch block (the 'manual' way) to decode instructions. Rather than write every combination of instructions out by hand, the code making up the switch blocks up is generated by another program, reading instruction information from a table copied from an Excel spreadsheet. At the cost of a significantly larger assembly (from 40KB to 140KB) I now get a 100% speed increase (from ~50MHz to 100MHz).
Compatibility increases further...
I've added better memory emulation (that is, handling ROM paging, RAM mirroring and enabling a BIOS or not). I wouldn't dare say "more accurate", as that might indicate that something about it is partially accurate. I've isolated one of the biggest problems - and that's programs getting caught in a loop waiting for an interrupt that is never triggered. The source of these interrupts is the VDP. It can generate two kinds of interrupt - on a line basis (where you can configure it to fire an interrupt every X scanlines) or on a frame basis (where it fires an interrupt at the end of the active display).
Screenshots galore
I downloaded a collection of homebrew releases from SMS Power! for testing. Here are the obligatory screenshots. Sega Master System
Copyright Violation is displayed incorrectly - the text should be on top of the stars, but that VDP feature is as yet unsupported. Sega Game Gear
Yes, Windows and DOOM were ported to the Game Gear. That second screenshot is DOOM's automap. There are still lots of ROMs that won't go - that could be due to poor VDP emulation, or it could be due to ROM paging errors (the emulated memory is just straight 64KB RAM), or could be down to the remaining bugs in the Z80 emulation.
Sega: Enter the Pies
The Z80 core is now a bit more accurate - ZEXALL still reports a lot of glitches, and this is even a specially modified version of ZEXALL that masks out the two undocumented flags. The VDP (Video Display Processor - the graphics hardware) has been given an overhaul and is now slightly more accurate. A lot more software runs now. I have also hacked in my PSG emulator (that's the sound chip) from my VGM player. It's not timed correctly (as nothing is!) but it's good enough for testing. Picohertz, the demo I have been working on (on and off) now runs correctly.
And now for something completely different
A long time ago I thought I'd try my hand at this emulation malarkey. The hardware is the Z80-based Sega Master System and Game Gear. Due to the design, it was a huge, messy, poorly written series of hacks that could just about produce the above result if you didn't breathe too hard. After finding this document, I had a bit of a blast at rearranging the Z80 core and timing the video hardware a bit more correctly. Here's that old Fire Track project:
All this does is run the emulation for 100 scanlines on a Timer's tick, hence the low reported clock speed.