RedSquirrel is a machine emulator for a number of different hardware platforms based on the Arm processor and as such it is not OS dependent.
It happens to be able to run RISC OS, an operating system written by Acorn, now owned by Pace. These are commercial products which I do not own and do not have a license to distribute or sell.
It should also be able to run ArmLinux, NetBSD, RiscIX etc.
Try using a search engine or try one of the links on the RedSquirrel site.
There are a number of different sites distributing the older RISC OS 2 and 3.1 roms.
For RISC OS 2 and 3.1 you will need four 720k formatted DOS floppies. At an OS prompt type
*save :0.$.rom1 3800000 3880000
*save :0.$.rom2 3880000 3900000
*save :0.$.rom3 3900000 3980000
*save :0.$.rom4 3980000 3a00000
Once for each floppy.
For RISC OS 3.7 you will need four 1.4Mb formatted DOS floppies. Reboot without running !boot (usually shift hard reset). At an OS prompt type:
*save :0.$.rom1 3800000 3900000
*save :0.$.rom2 3900000 3a00000
*save :0.$.rom3 3a00000 3b00000
*save :0.$.rom4 3b00000 3c00000
Once for each floppy.
Copy each of the sections of whichever rom you have saved into the relavent rom folder in RedSquirrel. They dont need to be joined together and as long as the names are in alphanumeric order and there is nothing else in the rom folder it should work.
There are a few reasons for this, but the main one is extra files in the rom folders (e.g. the zip file from which you extracted the roms. RedSquirrel will quite happily load zip files and try to run them as arm code.
This is the RISC OS self test telling you it's not happy about something. Typically this is because RedSquirrel can't run the video/sound timing accurate enough to pass the tests. Under RISC OS 3.7 it usually means you've copied over patched roms.
Eventually it will carry on and boot. You can turn off the 'Power on Reset' in the general options to stop this happening.
For RISC OS 2 and 3.1 you should probably have a copy of !System and !Scrap. These were distributed on floppy with RISCOS and used to be available from the Acorn FTP site. Check the links page for these.
For RISC OS 3.5 and up you really should have the universal !boot sequence which may be available somewhere on the web.
There are lots of different ways depending on the hardware you have
available but they all involve two routes, either via ADF files or HostFS.
RedSquirrel doesn't yet support reading Acorn disks from the PC floppy drive
but it does support reading 'disk images'. A disk image is a block
copy of the floppy disk into a file on your hard disk. You can use
a program such as arcimg that will read an Archimedes disk and write
an ADF file.
HostFS allows you to see part of your PC's filing system from within RedSquirrel,
much like a network drive. Any files in a HostFS folder in Windows will
be visible from RISC OS and vice versa. RedSquirrel does its best to preserve
filetypes by using Lanman98 notation, adding ,xxx types to the end of
each file. It also attempts to recognise common extensions and map them
to RISC OS filetypes. If you can get files onto your PC via a network or
dos floppy then you can use this method.
Acorn machines store extra information about files such as filetypes in way
that PC's don't recognise. In the same way that you'd zip up files before
emailing them to preserve information it's best to use Spark, PackDir or
something similar to archive your files during the transfer.
Not yet.
I occasionally release a version of RedSquirrel that is currently in development to get user
feedback. These releases tend to be much less stable than the normal releases.
There are a number of reasons why RedSquirrel could run slowly. Firstly it is a
very processor intesive program that requires quite a powerful PC to
emulate even an old Archimedes machine. You should curently expect to get
about 1 mip for every 100Mhz of processor speed you have on an intel PII/PIII processor.
RedSquirrel also relies on decent graphics an sound cards to take some of the load.
Software audio cards such as AC97 codecs will take a significant proportion
of your processor time and slow down RedSquirrel.
If you are running in 'hardware scale mode' and your graphics card cannot do 'Stretch Blitting',
i.e. if it can't scale in hardware, stretched modes such as 640x256 (mode 12/15) will be stretched
in software and this is very slow.
You probably need at least an 8Mb graphics card as RedSquirrel needs a separate display
(back) buffer.
Not all drivers are created equal. On my Laptop which has a Savage
IX chipset, the Windows ME driver scales in hardware but the Windows
2000 driver does it in software. Until I change to mode 31 (800x600)
with square pixels, RedSquirrel runs at 0.1 Mips under Win2k.
If this happens to you, make sure you are running in 'software scale' mode.
Two reasons, processor implementation and data bandwidth.
There are two common ways to emulate processors.
The first method is called 'Interpreted', is relatively easy to
implement and test but is slow and mimics how the real processor
works. Each instruction is fetched, decoded, and executed in turn.
Each time that instruction is reached again it will be fetched,
decoded and executed again. Fetching and decoding are surprisingly
expensive and take a large proportion of the execution time - around 75%.
Needless to say, this is the method currently used in RedSquirrel.
The other method is called 'Dynamic Recompilation'. In effect this means that
sequences of ARM instructions are fetched and decoded but before being executed
they are compiled into native (intel) code and stored. Next time that sequence
of instructions is reached, the intel code is executed directly. This will typically
give a 10-20 x speed improvement over the interpreted version in normal use.
Why doesn't RedSquirrel use the second method? Because this is one of the main
selling points of Virtual Acorn, the commercial version of Red Squirrel
Data bandwidth is really to do with the enormous amount of information flying around
on any computer even when it appears to not be doing much. The biggest of these is video.
Every 6 to 64 microseconds RedSquirrel copies a line of data from the VIDC video memory,
converts it to the windows pixel format and draws it to a buffer. Every 20ms or so this
is copied to the video display so you can see it. VIDC20 in a RiscPC can cope with up to
160Mb/sec of data which is more than can be sent over the PCI bus in most PCs.
RedSquirrel does its best to avoid copying data unless really necessary. If you use
graphics intensive applications which update the entire screen regularly then it will
slow down th emulation.
This is limited by the emulated hardware.
Vidc1, supported by RISCOS 2 and 3 had a limit of 512k for video/cursor/sound.
Typically this means a limit of 480k. There were add on cards that supported
more ram and these may one day be emulated.
Machines with a separate IOMD supported 2Mb of VRAM and RedSquirrel will happily let
you use up to 2Mb of ram for these machines
Machines with the Arm7500 chipset only supported DRAM. Much like in RedSquirrel, the
more DRAM you used for video, the less bandwidth there was available for the
processor. On a real machine this ram was quite slow so there was a limit to
the video memory you could use. On RedSquirrel, that limit doesn't exist so you can
configure screen memory up to 16Mb which is a VIDC20 limit. However, you will
need a similar amount of VRAM on your PC's graphics card to cope and a very
fast machine to blit that much data at a reasonable rate.
Because it isn't supported. RedSquirrel relies heavily on parts of DirectX
that haven't been updated on Windows NT 4 for a long time. I have
had RedSquirrel running very badly on NT 4 but it is unusable. I am planning
changes to the display code that will enable some form of RedSquirrel to run
under NT 4 but it won't be as fully featured as under Win98/ME/2000
For most people in most circumstances it isn't. You need a reasonably
decent sound card that does most of its work in hardware.
Occasionally RedSquirrel has a hiccup and the sound goes wrong,
especially on slower processors.
There used to be a number of older games on the web but many have been removed
due to copyright issues. Try www.riscos.org for a list of RISC OS software and
suppliers. Alternatively try the comp.sys.acorn newsgroups as there may be some
people willing to sell their old games. Some of the games distributors are making
compilation CD's with games updated to run on the latest processors. Hopefully
some of these CD's will contain ADF files for use with the emulators.
Most do work now but there are a few exceptions:
Some games were written for RISC OS 2 and don't run on later versions.
I'll eventually add support for RISC OS 2 to cover the first case and I'll
track down the other problems one day.
Because it doesn't work yet. RedSquirrel is a Win32 application and as such is
restricted to using the Win32 API. Windows doesn't support anything
other than 512byte blocks on floppy/hard disks and Acorn disks use
1024 byte blocks. There are two ways around this, neither are pretty
and neither work under Windows 2000. I had a half hearted attempt at
writing a VXD to give me bios access but it hasn't been entirely successful.
I will try again soon.
Yes, but there is no networking support so you cant browse the web.
Hopefully soon I will release the plugin API and someone can write
the networking support. It isn't important to me so I wont be writing it myself.
Not yet. RedSquirrel is pretty well structured for porting so it shouldn't take a Linux
or Mac programmer very long to port. However, I don't consider RedSquirrel static enough
for a port just now. Soon it will be and the ports can go ahead.
No.
Whatever happens, there will always be a freeware version of RedSquirrel for personal use.
The Arm7500 and the IOMD chip in Arm710 machines support different types of mouse.
*configure mousetype 3
RISC OS needs to be told that it's there. At an OS prompt type:
*configure idediscs 1
and do a Hard Reset.
Because the keyboard/mouse repeat rate is wrong. At an OS prompt type:
*configure repeat 8
Because the country code is wrong. At an OS prompt type:
*configure country UK
No. Suzi is the webmaster and Graeme does the programming.
She wrote all the HTML and javascript by hand.
The windowed effect is done with nested frames.
The same way as you would on a real machine. At an OS prompt type:
dir hostfs::diskname.$ (or dir adfs::4.$)
The best way is to go out and buy a 3 button or wheel mouse. However you can also program
the Windows 'Menu' key to act as a third mouse button. Typically this has an image of a
menu with a pointer on it.
Use the Keyboard options to select the button you wish to emulate (you may have to try a
few times to get it right).
Alternatively you can program your two mouse buttons to act as left and middle and set
the menu key to act as the right button.
Once you have the ADF image on your PC, use the Floppy icon on RedSquirrel toolbar
(not the RISC OS iconbar) to select the ADF. Then you can use the floppy icon on the
RISC OS icon bar to open ADF image like a real floppy disk.
and
Some use copy protection that cant be handled by the ADF reader.
Some just don't seem to work (Phaethon and Boogie Buggy for example)
If the pointer doesn't move, at an OS prompt type:
or
*configure mousetype 0
*configure delay 32
opt 4,2
conf. filesystem hostfs (or conf. filesystem adfs)
conf. boot