TwitterOSCA 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.
WRITEENABLE
Allow writes to SD card to be persisted to the real disk image
NOWRITEPROMPT
Don’t ask whether to commit SD writes to disk at exit/reset – assume a “yes” response
A sample config.txt follows:
BOOTROM roms/rom.binEEPROM F000 roms/bootcode.eprSDCARD 0 roms/flos.imgWRITEENABLE
Directory names can be included (as shown in the example),
and the path separator may be / or \ depending on preference.
Both work identically. Absolute paths or relative paths are OK.
2. Boot ROM – this must be 512 bytes exactly
3. EEPROM contents – anything can be loaded here.
The sample above shows a typical setup where the original rom and
bootcode are used. Using the original ROM means that the bootcode
image loaded from
0xF000
must be correctly checksummed as it would
on a real board. This further means that any operating system file loaded
into the EEPROM from
0x800
onwards must have the correct signature.
CAPABILITIES
1. PIC is simulated enough to load databurst images from the
(virtual) EEPROM. Data can be loaded to the EEPROM for this
purpose.
2. Z80 core with integrated debugger (of sorts!) with user-triggerable
reset and nmi
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
6. VGA mode display emulated – includes Blitter, Chunky Bitmap Mode,
Planar Bitmap Mode, Raster IRQ and active palette.
7. Maths Assist unit fully implemented
8. Basic SD/MMC Support provided – only single block read/write is supported, as well as
card identification requests and reset command.
9. Full Audio is supported, including IRQ trigger at the end of sample playback (where enabled/used)
INCAPABILITIES
Notably absent: Secondary palette,
tilemap mode, sprites, hardware scrolling
1. No Tilemap Mode (*)
2. No Sprites (*)
3. No LineCop (*)
4. No Joystick Emulation
5. Video modulo not implemented yet except for the blitter (*)
6. No Secondary Palette (*)
7. No Hardware Scrolling
(*) 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.
2. Probably much much more 😉
Download Binaries:
OSCA Emulator Binaries (3.7 MiB, 3,978 hits)
Download Source:
OSCA Emulator Source (134.1 KiB, 580 hits)
Download Experimental Build (Binary):
Caution: This is experimental. Do not attempt to resize the window, or use the processor controls inside the debugger window, as these will likely crash the emulator, and who knows what else?!!
OSCA Experimental Binary (519.1 KiB, 1,453 hits)
Nov 07, 2010 @ 15:54:05
Firtsyl, thanks for this great little emulator!!
Secondly, help! As per the config file.
EEPROM F000 roms/bootcode.epr
SDCARD roms/flos.img
But the emu can’t find either!! And they are in the roms folder, infact I’ve not altered anything from the original download!
Thirdly, is it still WIP? I’d love to see (hear) sound is being worked on!
Cheers.
NQ.
Nov 07, 2010 @ 15:55:36
And that is a piss poor attempt at typing “firstly”! Where’s the post edit? 🙂
Nov 07, 2010 @ 16:00:13
Weird, I deleted the config file, started again, put in it.
BOOTROM roms/rom.bin
EEPROM F000 roms/bootcode.epr
SDCARD 0 roms/flos.img
WRITEENABLE
And it works!!!
One thing though is how to create an img disk, and copy files onto it, I want to try Bounder and the spectrum emu etc.
Cheers.
NQ.
Nov 07, 2010 @ 16:13:58
Strange – not sure why re-creating the file helped?
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.
DT
Nov 08, 2010 @ 11:45:03
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!
DT
Nov 08, 2010 @ 18:36:47
Yeah tried bounder, but no luck! 🙁
Nice little OS on it though, DIR, CD etc. 🙂
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.
Dec 19, 2010 @ 10:12:53
I just downloaded everything and it works. However, after edit the file config.txt inserting value 0 on line specify an sd card image to mount “SDCARD 0 roms/flos.img”.
Just one question: if i test my own software, how can I place it in the SD image?
Thanks,
enzo.
Dec 19, 2010 @ 12:44:02
Hi Enzo,
There’s a couple of ways…
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?
Tony
Dec 22, 2010 @ 18:29:24
Thanks for the update DT!!!
Cheers.
Dec 25, 2010 @ 15:23:48
Yay, well sound works in Bounder, and VectorBalls2 demo.
How do you load the mods and pt3 ones? Is their a tracker available, or do you have to load them into a specific address and exceute that address?
Cheers.
Dec 25, 2010 @ 15:25:50
Ignore aboave, found modplay.exe for it.
Dec 25, 2010 @ 19:43:35
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 😉
DT
Dec 28, 2010 @ 17:43:09
Again, thanks for the update. Let’s see what it’s like……….
Sep 18, 2012 @ 15:29:38
In this way I got FLOSv599 (and v605) working on the emulator (older version 0.4):
C:\…\roms>ren FLOSv599.OSF FLOSv599.BIN
C:\…\roms>debug FLOSv599.BIN
-m 110 ffff 100 <- rip off the header
-rcx
CX 3FA4
:3f94 …..I……..
1404:3A10 D3 06 F1 C9 F5 DB 06 CB-D7 D3 06 CD 98 48 F1 C9 ………….H..
1404:3A20 F5 DB 06 CB 9F CB D7 D3-06 ………
-e 39ac 00 00 00
-d 39a9
1404:39A0 10 F9 C1 00 00 00 C5 …….
1404:39B0 06 00 CD 11 49 CB 7F 28-02 10 F7 B7 C1 C9 2A 74 ….I..(……*t
1404:39C0 4F E5 CD 11 49 77 23 10-F9 E1 C9 40 00 00 00 00 O…Iw#….@….
1404:39D0 95 48 00 00 01 AA 87 69-40 00 00 00 01 20 76 78 .H…..i@…. vx
1404:39E0 2E 78 20 53 4E 3A 30 30-30 30 30 30 30 30 20 00 .x SN:00000000 .
1404:39F0 00 00 00 00 00 00 01 00-D3 0A DB 09 CB 77 20 FA ………….w .
1404:3A00 C9 3E FF D3 0A CD 0A 49-DB 0A C9 F5 DB 06 CB 97 .>…..I……..
1404:3A10 D3 06 F1 C9 F5 DB 06 CB-D7 D3 06 CD 98 48 F1 C9 ………….H..
1404:3A20 F5 DB 06 CB 9F CB D7 D3-06 ………
-w
Writing 03F94 bytes
-q
Add_os_crc_header.exe -> follow the steps to transform FLOSv599.BIN in FLOSv599.OSF
..then obviously copy it in the SD image file.
The patch just removes the quirk workaround.
In details:
sd_sclp:
7e ld a,(hl)
cd0000 call 0 ; command byte
23 inc hl
10f9 djnz -7
c1 pop bc
CD >>>> call get_byte ; skip first byte of nCR, a quirk of the OSCA V6 SD card interface?
sd_wait_valid_response:
push bc
ld b,0
sd_wncrl:
call get…
…While in the earlier FLOS versions it was like this:
djnz -7
call get_byte ; skip ….
call get_byte
Sep 22, 2012 @ 17:08:38
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?
Best Wishes
Tony
Oct 02, 2012 @ 20:57:13
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 !
Oct 06, 2012 @ 13:53:35
Thanks for the feedback Stefano – I guess I misread your earlier post!
I thought this was a problem with the version reporting, but I understand now it’s the SD card reading.
I must say, Phil deserves a prize for his continuous support of FLOS – top stuff!
Out of interest – do you plan to support the Z88DK on the V6?
Mar 13, 2013 @ 10:09:04
Hi Tony,
is the custom version of CP/M 2.2 with your name in the V6Z80P CP/M BIOS
available as Download?
Will it run only in your OSCA-Emulator or also in the original V6Z80P?
Mar 15, 2013 @ 09:00:05
Hi Guido,
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.
Tony
May 22, 2015 @ 06:43:58
do you know how to create a working sdcard on real hardware ?
i cannot manage to get one formated correctly to be recognized…
thanks