Speculating on possibility/difficulty of emulating Tandy 1000 (IBM PCjr clone)

Dennis Ferron

I've been following the progress of the C64 emulator on the forums and I think it's really neat, but... the C64 was a bit before my time. There's a lot of people who have all the tools/experience for the C64 but since I never owned one, I feel kind of left out.

But now x86 assembly, DOS, and the Tandy/IBM PC XT, PC jr and clones thereof, that I really got into. Technically those were before my time, too, but my family was poor and I grew up with 2nd hand computers that were 8 - 10 years older than what everyone else was using. To do an emulator it seems to me that you have to have a real in-depth knowledge of obscure and even undocumented hardware "features", and if there's one system I know that well, it would be those original 4.77/10 MHz 8086 machines. Heck, I used to be able to look at the raw machine code (in hex) and know what the opcodes were - who needs a dissassembler? I grokked raw machine code. Haven't looked at it in years though.

Also I've still got my old original Tandy 1000 and recently acquired another Tandy 1000. That means I could tear one up to probe the hardware and still have another running version for reference.

The BIOS of the Tandy was stored along with DOS 3.3 on a giant ROM chip. That I could dump to make an image to execute with the emulator. I could use an SD card to emulate a hard drive.

Speed should not be a problem - surely the Propeller could emulate a 4.77 MHz 8086 chip, maybe even a 10 MHz one. The Tandy graphics mode will be a problem, because 320x200 x16 colors would require all 32K of RAM. I would like to be able to play Sierra games though. Maybe it would be possible to display a reduced resolution and 4 colors, but make the program think it is all there. Video to video BLITs would probably generate a lot of garbage though.

The biggest problem will be coming up with 512K of system RAM. I don't want to use EEPROM - too slow and it'll wear out if it's used like this. I am not aware of any I2C RAM chips this large, maybe someone knows of one? Another option might be to use dynamic RAM modules pulled from old computers, or surface mount SRAM chips on a carrier with a parallel interface (data and address busses). Might have to deviate from the demoboard/hydra schematic to get it to work. Or even need a 2nd propeller.

How about a Hydra add-in card with a RAM module and a 2nd propeller on it that turns your Hydra into a Tandy PC? Or, screw the processor emulation entirely, but emulate the hardware only. How about a Hydra card with an 8088 and some RAM on it that works with the Propeller in your Hydra to run Tandy games?

Dennis Ferron

More ideas, based on the way my suitcase computer handles it's 68000 processor and RAM: A Hydra card with an 8088, a 1Mb DRAM module, and some shift registers. The 8088 is connected directly to the DRAM module which is big enough to hold all of the system RAM address space and video address space. 8088 accesses to RAM run at full speed, and I believe the 8088 has DRAM refresh built into it. The Propeller on the Hydra intercepts just the I/O requests to emulate hardware, and snoops on the contents of video RAM to mirror it on the TV or whatever. (The shift registers are to allow the Hydra to access the address, control, and data lines with just a few pins.)

RobotWorkshop

Hello Dennis,

I would avoid using the DRAM unless you have to because of the extra work dealing
with the refresh of the memory. It gets pretty messy and you'll probably need extra
hardware just to handle that. On one of the memory cards I designed for an older
HERO 2000 robot I use one of the 512K static RAM chips. They are not too hard to work
with and you don't need to worry about refreshing them. Also, I believe Dallas still
makes a NVRAM version of if (DS1250??) but i'd have to look up the part #.

It may take a couple of Propellers to do the job. One for the display, keyboard,
mouse, and I/O, and another to emulate the CPU and the main system. It's not
trivial but I suppose it could be done. I've got ton's of old books on these types
of machines, the PC BIOS, and related material. I can help point you to some good
sources of information that would help if you choose to pursue it.

Best Regards,

Robert

RobotWorkshop

Since you're on the Topic of emulation it would be cool to look at the MAME
source and see about porting at least a portion over to the Propeller. That
would be cool since you could perhaps have your favorite arcade game
loaded on it ready to play....

Robert

asterick

Most arcade games tend to have several memory chips, as well as several processors. Most of them have at least 2 plus a synth. (any game made after 1980 at least) You'd be hard pressed to squeeze one into the current propeller.

JT Cook

Emulators are a tricky thing because they are pretty resource hungry. Right now I am working on a C64 emulator(not for the propellor) and it had me thinking if I were to try to port this over the prop, how would I attempt this?(And no I am not going to try and write one, so don't ask).

It·has 64k, plus memory for Kernal Rom, Basic Rom, Character Rom, VIC2 registers, CIA registers, and·SID registers which can be banked in and out of that address space, we will push it to 128k for a good even·amount of extra memory.

THe first problem we run into is memory addressing since that would take up most of the pins on the chip. We can use some kind of serial shifting at the cost of speed (with the system running at 1mhz·could still·be feasable).

The next problem we run into is each COG is can only have 512 assembly instructions. If you do not have enough code space to put the CPU core into a single COG and have to write it in SPIN, you will lose a good chunk of speed and a good chunk of Prop memory.

The last problem we run into is video. Even though the highest TV resolution drivers are running a 256 horizontal pixels it is probably feasable to have a TV driver that runs at 320 horizontal pixels. But how most of the advance Hydra video drivers work is that there are multiple scanlines that are rendering in tandom. This creates a huge problem if you are trying to read any external memory because the COGs run in parallel so they might try to access the external RAM at the same time, which really wouldn't work. So now we have to store the memory that the VIC 2 can see in the prop memory (which is 16k) and now cuts our prop memory in half. There are still issues on timing for video effects like sprite muliplexing.

Now if you want to try and emulate something, I would shoot for the Atari 2600. The ROMs are usually 2k-8k, and has I believe 128 bytes of ram. So even if you had to write the CPU core in SPIN, you should still have enough memory left over ROM and RAM. Though you still have the issue of CPU timing to deal with.
·

Bean

I would love to see a ZX81 (Timex Sinclair 1000) emulated.
It wouldn't be too hard the video is simple, and they only had 8K ROM and 2K RAM (1K for ZX81).
It's one of my favorite computers.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

"USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population." - David Letterman

rokicki

Right, I've been thinking along these lines (again, without any commitment to do anything). But here are some of my thoughts.

First, the CPU emulator can sit across multiple cogs, with each cog handling a subset of the instructions or addressing modes,
and them all working "together" on the same scratchpad in main memory. Each cog peeks at the opcode, does what it can.
This way you can "multiply" the code space.

I think the Atari 2600 is probably doable; the 6502 is simple enough. But as you say, most games for the Atari 2600 are
very timing sensitive so it would be tough.

My personal goal (again, just for kicks, and only just looking at the ideas) is to try to get a 4K ColorComputer with the 8K
BASIC running on a single prop. I think it's doable. (It would not be very *useful*, but I think it's doable.) It would
require some pretty clever programming though. If I can get that to work, it should be possible then to get a 32K or 64K
Coco with the Extended Basic on the Prop2. Then we'd be cooking with gas.

asterick

Timing sensitive is a gross understatement on the atari 2600. [noparse]:)[/noparse] Not to mention that it's bus capacitance sensitive too.

Floating pins actually affect gameplay.

Dennis Ferron

Including a real 8088 would eliminate the resources needed for it's emulation and ensure correct instruction timing, but accessing the 8088's parallel memory from a Propeller would indeed eat me alive on timing and pins. My suitcase computer uses 8255's to access RAM in a 68000's address space, but it is only an (unfinished) proof of concept; it will probably be very slow in practice. The only reason to do it is so I can run C programs with a 68K cross compiler and use up to 256K of RAM.

I'm interested in hearing what other machines people are interested in emulating, too.

RobotWorkshop

Hello Dennis,

If you were taking a Hybrd approach and use a reall 8088 then just connect
the 512K static RAM directly to the 8088 and don't worry about that. Hang
the probeller on the bus and interface to it like the regular I/O devices would
be handled. With that you just need to 8 bi-directional data lines, some control
lines and enough of the address lines to decode the stuff you want to emulate
in the propeller.

Robert

Dennis Ferron

I have a 2nd Propeller chip and some 8088's and enough breadboard space left in my suitcase computer to prototype this. It'll have to wait until this summer though because all of my things are in storage while I'm away. I think the best way to do it would be to use 2 propellers (which I think Robert may have been getting at -?). I would have a Propeller dedicated to nothing but talking to the 8088 and RAM, and a cog in that one can relay things to a another cog in another propeller which is connected to the video and keyboard. That way you get all the pins you need and (hopefully) enough Propeller CPU power to handle it all. Now remember, I need Propeller pins to not just access data and address lines, but also to connect to the 8088 control bus. However, if you look at the way that the 8088 works, the data and address pins are multiplexed (D0 - 7 and A0 - 7 are the same pins). So I have to have a latch anyway to latch the address. If I connect the Propeller to the 8088's side of the latch, then I get to use the same latch "for free" and save 8 Propeller pins by multiplexing the same way the Intel designers did for the 8088.

I found an 8 Mbit (1 megabyte) SRAM chip from Dallas semiconductor. It has built-in battery backup, which I don't really need, but it also won't cause any problem. There may be other chips even better suited - know of any? Anyhow, although I only need 512K to emulate a Tandy, remember that I want to have video RAM in the address space too, which requires RAM, and if I have 640K I can make it a generally PC-compatible computer. A 1 MB chip neatly covers the whole address space of the 8088, so all my bases would be covered. Also, on newer machines with more memory, later versions of DOS had the option of loading drivers into "high" memory to free up the base 640K. This can be really important - some DOS games squeak by with so little extra room in memory that they almost cannot be run without the memory freed by loading DOS into high memory. I believe the DOS high memory feature works by assuming all "empty" spaces in the memory map are really mapped to system RAM. Therefore, I'd want all of these spaces to also map to RAM on my emulator.

Someone asked me if I intended to transfer my suitcase computer circuit (with 68000) from breadboard to a permanent soldered project when it is finished. The answer was no, because it is intended as a microprocessor experiment lab and will always be in a state of flux. But if I can pull off this 8088 + Propeller DOS machine, then I will definitely take a Propeller protoboard and build it on one. I'd been trying to think how I could justify to myself what the point is in building a PC-XT emulation machine out of a Propeller when it is so much easier to run a PC based emulator or to find a real old XT machine. What I realized is that I might be onto a way to build an x86 compatible computer with a smaller size and far fewer chips than usual. Sure, you can get a DIMM PC, but all of the one's I've seen are a little expensive, and sure there are systems on a chip that do whole computers with one chip. But this is a way for a hobbyist to build a homemade PC compatible from raw chips without having to actually wire up as many raw chips as you ordinarily would! I've been talking up how the Propeller is revolutionary because it allows you to use software to replace dedicated chips (I know you could always do this but the Propeller makes it much more practical!) and I thought, well, isn't this a perfect example of that?

I'm a big fan of Ben Heckendorf (www.benheck.com). He's the one who was famous for making a portable (handheld) Playstation 1 by shrinking down a full-size Playstation, before the Playstation Portable ever existed. He's done quite a few more systems than that though. His works inspire me to want to make my own portables. I know that I lack the aptitude for fabrication and design taste he has that allows him to make such beautiful works, but I do have the ability to build entire system circuits from scratch (something he mentioned on his site that eludes him). Though I would not diminish any appraisal of the skill he must have to slice entire boards apart and solder them back up so that they work, I should note that while he can take circuit boards that already exist and make them beautiful, I can create circuits that never existed before at all. It intrigues me that with all of the classic gaming systems he has done, he has never done a portable that plays classic DOS games. This is an area ripe for exploration, and a PC that requires only so few chips as this "Propeller XT" hybrid emulator could be small enough to be the basis for a handheld DOS game machine.

RobotWorkshop

Hello Dennis,

Depending upon what peripherals you decide to implement in the propellers you may not need to connect all the address lines of 8088 to the propeller(s). Most of the address lines are only really needed for memory access and if the 8088 is going to deal with that then just decode some of the higher order address bits to deal with the sections you need. As an example if the only memory that the propeller would have to deal with would be the section that is memory mapped then you could perhaps use a GAL to decode the upper bits and just flag if is is trying to reference an area that would be video memory. If so then just use enough low order bits to determine the exact location in that area.

In a lot of cases the peripherals were I/O based and did not need all the address bits decoded to select them.

I'll have to search through some boxes in the basement but I think I have some parts that would be extremely helpfull in a project like this.

Hope this helps...

Robert

Dennis Ferron

Actually, with the help of a custom BIOS, I could get the 8088 to read and write my memory for me! Technically all I need to access with the Propeller is just enough RAM to build a small bootstrap program in the 8088's address space. Just 256 bytes could be enough - and then I would only need 8 lines, because the 8 address and 8 data lines would be the same pins, muxed together. Once that is done the bootstrap could copy itself into a different memory location and use the small "shared" RAM location for communication with the Propeller. The Propeller could cause an interrupt every time it wants to access the 8088's memory map, and the custom 8088 BIOS would inspect the small shared buffer and see, oh, the Propeller wants to read 27 bytes from memory location 0xB000, I can do that, here you are, and it would copy those bytes into the 256 byte buffer.

IIRC, the x86 processors actually jump to FFFF:0000 upon reset - the top of memory, not the bottom. I could either hardwire the Propeller into the top 256 bytes of RAM, or I could let the 8088 execute garbage on power on reset and "rescue" it by asserting an interrupt that causes it to execute low memory (the interrupt vector is down in low memory). On second thought, I probably better stick with wiring the Prop into upper memory, because I don't want to have to trash the interrupt vector table every time I use the shared buffer for communication. If the Prop lives in the FF00:0000 to FFFF:0000 range, it will cover addresses that usually map to BIOS, and since I am writing my own BIOS, I "own" that area anyway.

I don't know if 8 address lines is enough to uniquely identify all the common port accesses (COM, LPT, keyboard, etc.) but since not all address are used, to recognize a, for instance, 13 bit magnitude port address, I don't actually have to wire all 13 lines, just the ones that uniquely identify it from other ports used in the PC.

Robert, you've been giving me some great ideas. I think this thing could actually work....

Dennis Ferron

Just to clarify a point of confusion here, I don't need to catch memory accesses with the Propeller because I am not going to directly intercept writes to video memory at all. Instead, I am going to let the writes to "video" memory just go through to the same system RAM chip that everything else does. The Propeller will inspect the contents of the "virtual video RAM" periodically and change it's internal bitmap based on what it finds. This won't give me as many frames per second output on the Propeller's display but will take less resources from the Propeller, allow the 8088 to run faster (no waiting for emulated video writes), and it will give me various options for post-processing the video image before I display it. For instance, I could shrink the image to fit a lower resolution, or I could display only a portion of the virtual screen at a time and let the user scroll the display to see everything.

I/O requests I will directly intercept and return emulated data for, but to trap those I just wait for the IORQ/MEMRQ line to transition from "memory" to "I/O", and then put the 8088 in a wait-state while I figure out what data that emulated port should return.

With just 8 combined data/address lines, I could probably do it all with one Propeller, not two, and still have lines left over for keyboard, mouse, and video.