OSCA Emulator

The OSCA emulator emulates the standard configuration designed for the V6Z80P board. When first run, the IPL code is run and this loads the bootstrap loader from EEPROM. A picture of the bootstrap loader is shown below:

OSCA Bootstrap on V6Z80P

From here, the FLOS Operating System is loaded from the emulated SD Card image and boots:

FLOS on emulated V6Z80P

Emulation of OSCA is somewhat limited at present: much of the graphics subsystem is not yet emulated, for instance. However – bitmap graphics mode is fully emulated as can be seen in this 512K Big Blit Demo:

Big Blit Demo for FLOS on V6Z80P

With a little creativity, it is also possible to run other operating systems. Below is a screenshot showing a custom version of CP/M 2.2 running inside the emulator:

Custom CP/M 2.2 running on emulated V6Z80P

Configuration

In the main folder containing the emulator (once you have unpacked it, of course!), the file config.txt contains the configuration options for the emulator and can be edited using notepad (or similar text editor). Available options:

BOOTROM filename

Load contents of filename as the boot ROM image (at location 0x0000)

EEPROM address filename

Load contents of filename into the virtual EEPROM beginning at hex address specified

SDCARD address filename

Load contents of filename as a “virtual” disk image. Address is unused for now.

3. Ability to view certain device I/O calls as they are made in
a separate Diagnostic Monitor

4. Most I/O ports and MMIO implemented correctly, although many
entries return dummy values due to missing hardware emulation. All
memory banking is implemented, including new “entire 64k” mode
introduced in v0656 OSCA.

5. Keyboard implemented in a very basic manner. Clock and Data lines
are not yet returned back to the emulator

(*) These features are mostly included in the Experimental Build (with some limitations – no sprite mirroring for example) at the cost of performance

KNOWN ISSUES

1. Speed indicated inside the emulator is incorrect at the moment, and the
autothrottle routine does not perform correctly. This is because the CPU
execution is not performed in a separate thread as it would be in a “final
version”, but polled using a timer to aid debugging.

You won’t be able to try the spectrum emu – this is a different hardware configuration for the board that basically implements a spectrum, but at slightly wrong clock frequency. Not supported at all by the emu.

As for Bounder, I thought that was on the sample disc image to be honest, but doesn’t work properly on the emu yet – still much to be completed!! IIRC, it uses an unsupported video mode (from an emulation perspective) as I’ve not emulated the tilemap modes yet.

The disc images themselves for FLOS should be FAT images, so you should be able to open them using WinImage (or similar). There’s no emulator support to open/mount the images yet, so they’re just raw SDCARD images (512 byte sectors)

It is WIP, but the sound is presenting some issues at present. I’m not actively working on it as my main project, but I do come back to it from time to time.

Also, forgot to mention before that as OSCA is constantly evolving (the hardware is based inside a programmable Gate Array, so can be modified through software), it’s a catch-up game to implement it all!

Look forward to an updated version when it’s ready. Indrdible that the hardware was taken to The Breakpoint 2010 demo party with a nice little demo showing on it. Wish there was more available for the hardware, apart from the bloke who created it, there doesn’t seem to be much code about for it.

The first is to mount the image (you can do this under Linux using loopback, or Windows using a utility whose name I have forgotten – I will look it up again as I think one of my earlier mailing list posts made reference to it).

The second (and imho simplest) is using WinImage which is a paid app unfortunately, which allows deleting and injecting files and directories through a gui and drag-and-drop.

In time, I’d like to add virtual drive support (like UAE for example) but haven’t had time yet. I could also add a “load binary” option to allow injection of files into RAM if that helps?

Yup – modplay for playing mods, and imaginatively enough pt3play for playing pt3 files hehe.

The PT3 stuff is basically emulating an AY chip through software in real-time, so it’s not perfect, and the MOD playback is limited by RAM – this means only 4 channel mod files, and must fit into 128k or thereabouts, so no monster file sizes 😉

Nice patch! I can easily change the reported OSCA version in the emulator – I chose not to do this because I didn’t implement the actual changes from OSCA, so it might mean some software doesn’t work as it relies on features not really implemented.

Maybe in a future version I can add a config option to allow setting the reported OSCA version to whatever you like?

Phil is now aware of the problem and the latest FLOS sources (in SourceForge) are patched in such a way that they are compatible with both the emulator and the real thing; I wouldn’t say it is a trick, he just cleaned up the earlier sync phase happening before a command is being sent to the SD card.
So the next FLOS version will be able again to boot with your emulator !

It isn’t available for download currently. Unfortunately I lost the source code to it, so I’ll have to dig around and see whether I can find the package in my email or something. If I can find it then I’ll certainly make it available and let you know!

It will run on an original V6 board (or certainly used to), although I haven’t tried it with newer versions of the OSCA configs – If I recall correctly it required a disk image to be raw-written (using dd or rawrite) to the SD card, so you’d need a spare card to use it.