The
M.I.C.E. Project:
The [World's]
Most Ill-Conceived Emulator
Return to the Vavasour family
web site : Jeff's home page : TRS-80 Emulation Page
Contents
The Story Behind the M.I.C.E. Project
The M.I.C.E. Project Rules
My TRS-80 Model I Emulator, under M.I.C.E.
(includes download)
Links
The Story Behind the M.I.C.E. Project
It was an idea bread at a moment of insanity... retro, recursive. Back when I first got into emulation, it was 1989 and the challenge was to get something resembling a TRS-80 Model I going on a 7.16MHz Tandy 1000. What I produced printed things out in teletype fashion. Obviously, a bit slow. When I got my 20MHz Tandy 2810HD notebook in 1992, the challenge was renewed, could shrewd Intel assembly language coding interpret TRS-80 code fast enough to make real-time recreation possible? I found the answer to that challenge, after much effort, was, "yes!" Soon, I was emulating the 4MHz TRS-80 Model 4 in near real-time on my 20MHz notebook.
As emulation started to take off on the Internet, the new approach to emulation was platform independence, which led to C-based code. It was portable, but you needed a goliath 200MHz system to get anything approaching real-time speeds. Well, that was a different challenge.
Today, though, what do we have? 3GHz+ CPUs. On a basic level, not counting memory and bus issues, that's 150x faster than the notebook on which I struggled to achieve 1:1 speeds. One of the maintenance issues people email me about on my old emulators, these days, is, "how can I slow this thing down enough so it's usable?" (The answer to that question for most of my emulators is in the appropriate section on my TRS-80 Emulation Page, incidentally.)
Where's the challenge in that?
The first time I got into emulation, it was to take me back to my hard-core programming roots. To-the-metal assembly coding on a PC was necessary to make it work. Well, my newest idea isn't exactly hard-core programming, but it does take me back to my roots.
I recently noticed that some quick-and-dirty utilities I was writing in QBASIC to do file processing -- simple math stuff, etc. -- were running faster, in QBASIC, than they would've in optimised assembly on my Tandy 1000! Well, that got me to thinking... how fast would an emulator run on one of these machines, if it were written in BASIC? Though, the thought continued, QBASIC is too kind and the p-code runs faster than interpretative BASICs of old. My Tandy 1000 (and 2810) came with GW-BASIC. So, to see just how far computers had come, why didn't I try to do the absurd? Write an emulator in GW-BASIC.
It was in the heat of a deadline at my day job, but as a break from the hectic work pace, I decided to tackle the problem in one very busy and sleepless weekend. The result was an emulator, which, with the consent of the publisher, can actually be found hidden on the commercial product I recently worked on. (I think I'll leave people guessing for a while. Easter egg hunts are fun.)
The second emulator I did under the M.I.C.E. rules is a TRS-80 Model I Emulator, and it's included here.
Here are the basic rules, extracted from the program listing of my as-yet-undisclosed first M.I.C.E. emulator that was issued as an Easter egg:
1 ' MICE: the world's Most
Ill-Conceived Emulator, Version 1.1
2 ' Created July 19, 2003 by Jeff Vavasour
3 '
4 ' Issued as a challenge to the emulation community to bring
retro to a
5 ' new level! (When this thing runs too fast, it's time to stop.
Trust me.)
6 '
7 ' The rules: must run in GW-BASIC 3.22, QBASIC and QuickBASIC;
must not use
8 ' PEEK/POKE, any other direct memory access or call any
non-BASIC
9 ' code; no inline comments; two letter variable names, max.
To clarify one point, this means the same code must run in all three environments without modification, which means line numbers are necessary. Also, no calling of external programs outside BASIC (e.g. via SHELL) to access extra functionality. It must run in BASIC without assistance from anything on the outside, or any exploitation of the memory map via PEEK, POKE, VARPTR, etc.
BTW, I know that you can get variable names longer than two characters in GW-BASIC, but I want to take us to a time slightly earlier than that. :-)
My TRS-80 Model I Emulator, under M.I.C.E.
Be warned, one thing I didn't want to do in this initial offering was offer a finely-tuned, performance-optimised emulator (to the extent possible under BASIC). The code intentionally has room for improvement. For example, you might see "GOSUB xxx:RETURN" where "GOTO xxx" would obviously be a better savings. I wanted to lay the basic ground rule example without making things too esoteric and undecipherable. (The rules forbidding comments and descriptive variable names ought to be effective enough, in that regard.)
So, that said, the link below will take you to a program listing for a TRS-80 Emulator that will run in GW-BASIC and QuickBASIC as a 16K TRS-80 Model I. Due to the rule of no circumventing BASIC to gain extra functionality, and the fact that GW-BASIC lacks the ability to see if a key is held (you see only the initial key press and key repeats via INKEY$), the keyboard emulation is a bit convoluted. When you press a key, it holds the equivalent TRS-80 key down for a while, then releases it on its own. There is an alternate "sticky key" mode where pressing a key the first time presses it on the TRS-80 keyboard, and pressing it a second time releases it on the TRS-80 keyboard. The good news is that the code actually does remap your PC keyboard layout to the TRS-80 equivalent (so that you can use the real quote key rather than Shift+2 to generate a quote.) Special keys are as follows:
The one short-coming (and I, or someone else, can work around this in a future version) is that in QBASIC (as opposed to GW-BASIC and QuickBASIC) it emulates a 4K TRS-80 Model I instead of a 16K TRS-80 Model I. Though I haven't done it here, it's possible within the rules to do a 48K TRS-80 Model I or more, but it would require storing bits of TRS-80 memory in a file when it's not in use, since it wouldn't all fit in QBASIC's available string space at once. (Remember: no PEEKs or POKEs!)
Note: this emulator requires the same ROM image file, ROMIMAGE, as my MS-DOS-based TRS-80 Model I Emulator. I do not provide this ROM. It is copyrighted material. You must follow the instructions accompanying the MS-DOS based emulator to obtain it from a real TRS-80 Model I.
Download M.I.C.E. Project's TRS-80 Model I Emulator
If there's any interest in the M.I.C.E. Project from other sites, email me and I can link them here if there's M.I.C.E. content. If you just think M.I.C.E. is an insane idea, you don't need to email me about that. I know that already.
All content ©2003 Jeff Vavasour. Updated November 24, 2004.