Emulator rationale

EEA index

FileStore
Description
Hardware
Error codes
NVRAM
Disc format
Disc image
Accessing
Password file
E01 vs E01S
Rescuing
Emulator

Executable
Source
EPROMs
Mem. map
Licence
Versions
Modules

SD card

Intro
MDFS
Others
Clocks
Bridges
Interfaces
Misc h/w
Testing
Misc info

An E01S emulator!

First, let's admit one thing. I have been ill recently. A nasty cold. Spells sitting on the bog for longer than nature intended. You don't need details. Now, I don't know if it is a whole lot of snot stuffed into my head and compressing my brain, or what, but when I find myself feeling like this, I usually get the thought of "gee, why don't I write an emulator" (and if that's not a sign of terminal geekiness, I don't know what is!). The Amélie emulator was written in bouts of feeling unwell (since, erm, 2003...). I have written an emulator of a Casio calculator (complete with a photo, press the keys!) but I don't know where the code for that is. In fact I was so muddled I'm not even sure I can remember what operating system it was for! I also once wrote an emulation of a 2K phone book databank thingy complete with fake Japanese messages! だめ! こんにちは!

This year? Specifically April 2009. I began work on a FileStore emulator...

Like, um, why?

Two reasons, actually. The first reason is because I have never actually written an emulator for a specific hardware device to run specific code on. I mean, Amélie is a 6502-based computer board to run my own BIOS and firmware, but the problem is that it is my emulation of a 6502 as I understand it, and it is my firmware coded for the 6502 as I understand it. Which may not match reality. Let me give you an example. It would be trivial to 'decide' to word-align the 6502 opcodes to make debugging easier. While I am there I can add a few 16 bit operations (although the 6502 cycle for cycle can already kick a Z80's butt). Oh, and an instruction to swap X and Y. No reason, except it looks like it is missing one. All good and well... until I run the code on a real 6502 and it crashes after a milli-microsecond...
These are all radical examples, but it is possible that I have misunderstood some tiny little nuance, like what exactly Carry does in SBC and then write the firmware based upon this error, and the (incorrect) firmware will work fine on the (incorrect) emulator...
...so it will be a refreshing change to implement a system (correctly or otherwise!) which will be running code from someplace ELSE. The firmware is correct. It may not be 100% bug-free, but we have the definite advantage of:

It is designed for reliability. In my time using the FileStore at school, it never keeled over in a sulk. It complained about too many users, but that's because dumb-ass IT teacher turned off the rest of the room using The Big Switch and rarely allowed time for anybody to log out.
It has been deployed. As in used, in hundreds (?) of actual units running actual hardware and actually working.

All of this adds a level of assurance. If the emulator fails, it is my fault, not a firmware error.

The second reason is because I would like to add a harddisc to my FileStore. No real reason really as I don't exactly use the FileStore much nowadays, but I have a suspicion that there are a number of people who would be eager to have some options with their own FileStores.
I have a ~200Mb SCSI drive around someplace. Now I can fiddle with the firmware and I can fiddle with erasing and reprogramming the EPROM; but we have a long list of potential problems:

EPROMs have limited erase/reprogram cycles.
It takes time to erase an EPROM. Like 10-20 minutes. The UV lamp in the eraser is also life-limited and I've no idea where to source a replacement.
Programming the EPROM is physically fairly quick, however my arrangement is a Micron EPROM programmer hooked to a tempermental A5000 via a 1MHz bus running at 2MHz (! the user I/O podule) and then to the RiscPC via a crossover ethernet cable. As you can guess, the minute spent burning the EPROM is negligible compared to the hour of pain getting all that crap working.
I'm not a whizz with 6502 code. There are some people that can disassemble from a hex dump. I bow in their presence. It would be so much easier with the actual FileStore source to work from, but in lieu of this we'll have to work with the EPROM contents and a hell of a lot of patience. With this in mind, the error rate will go up dramatically, like that global warming prediction in An Inconvenient Truth (the bit where Al Gore gets on this trolley thing and goes up to another screen - that's our error rate).
With the above in mind, how much physical stress will be caused by repeatedly inserting and removing EPROMs from the FileStore? In essence, once is about all we really want. To change regularly we'd really need to desolder the chip socket and fit a ZIF in there. And pray we don't do something really stupid at 4am after a moody debug session like, you know, put in the EPROM the wrong way around...

So it seems to me that with no obvious access to the firmware source, the best we can do is to write an emulator, fake up the hardware, and see if we can get our fake hardware running as we would like. This will include (eventually) such things as the 200Mb harddisc which may or may not have parity. It would also be extremely useful to machine-poke some code directly onto the FileStore to allow harddiscs to be formatted instead of that entire annoying rigamarole that would be required otherwise. The MDFS got this right - go to some sort of supervisor mode, do it all on the server. No bullshit.
Can the FileStore access an entire ~200Mb drive? If not, why not? SIN limitation? Can we partition it, or will we need to section off a bit and 'pretend' the rest does not exist? Can we be flexible in what harddiscs we will work with?
The FileStore apparently has some level of notoriety for being overly fussy about what it will accept - why? limitations in hardware? limitations in software? or both?
I really do not expect to whack in a 64Gb SCSI-3 drive. Don't get me wrong here. But do be aware that the world has more than enough good SCSI-1 drives in the range of 200-600Mb. The specific correct 20Mb and 40Mb Rodime drives are somewhat thin on the ground, and actual proper Acorn-formatted ones are, frankly, non-existant. It seems to me to be stupid verging on annoying for a piece of functional hardware to be limited in such a pointless way. Why can't I locate an old original-SCSI disc, plug it in, and have some sort of useful result?

This is where the emulator comes in. For I fear it will be a case of hacking the hell out of the firmware...

There is a third reason: why not? There are a number of emulators for more common 6502-based machines - the Beeb, the AppleII, even the Oric.

Why not amend an existing emulator?

This might have been a possibility, to tweak one of a number of BBC Micro emulators or ask the relevant programmer(s) if they would be interested.
This is indeed possible, but may not be viable, for a number of reasons. Firstly, I am not aware of a Master Compact emulation on any of the current emulators. Fair enough, what a Compact can do, a Master can do better. However it shows that there is perhaps not enough call for specific emulation of one of the less popular machines.
Now let's look at the FileStore. It was written by Acorn. It's heart is a 65C102 (which I think is close enough to a 65C02 to pass). It contains a VIA. It contains an ADLC.
Ummm... That's it. Sorry. While there are numerous BBCisms in the firmware, like OSBYTE and such, this is of little relevance to the emulation.

Shall we look at the differences now? 64K EPROM copied into 64K RAM, EPROM then mapped out. Expects two floppy drives and perhaps a harddisc. NVRAM, same as in the Master or not? [I'll need to check this] No output, no VDU, just a printer port. All hardware is memory-mapped in page &FC (aka FRED in BBC parlance). It's a 2793 FDC as opposed to the 8271 and 1770 variants used in the eight bit machines.
In the future I plan to implement a sort of dumb terminal to allow commands to be passed to the server as if via Econet (so you can log in, etc). What emulator author wants to look to that alongside all the other stuff?

In order to aid in screwing around with the firmware, it might be useful to have a 'window' on the status of the hardware, disassembly, memory editor, etc. Most 6502 simulators have this functionality, but it is not common on emulators.

So, therefore, I figured the best option was to try to "roll my own". And I invite you to help me. Join in! Download and hack away! Let's get this thing built! ☺

State of play

This emulator is written in Visual Basic.
Okay, you can stop laughing now.
I wanted to concentrate on the task of writing the actual emulator, without wading though the multiple screenfuls of crap required to get a Windows program written in C to do anything at all.
Sure, it would be so much easier in C - for a start VB (up until .Net?) does not have any way to binary shift. You need to mul or div by two for each bit shift which is bordering on the retarded. Anyway, we aren't in this for speed. We aren't here for zippedy-dodah. We aren't here to run some fussy hardware-beating retro game. In fact, I am going to have to concentrate long and hard on making the disassembler, breakpoint, and debug tools be friendly and useful, for I suspect we'll be there a lot. So the CPU runs 2,000,000 cycles (one second) in around 4 seconds (450MHz CPU). SO WHAT?

To know in more detail what the emulator can and can't do, refer to the sources, the versions log, or download it and try it!

Return to FileStore emulator