8086 CPU XBYTE emulator working
TonyB_
Posts: 2,123
in Propeller 2
I have written and tested an XBYTE interpreter/emulator of the 8086 with the following features:
- Single-cog, all emulator code in register and LUT RAM only.
- Floating-point/multi-processor instructions excepted it does a full emulation.
- A few 80186 instructions added plus one from the 80386.
- Single-stepping supported by setting Trap flag.
- Hardware interrupt supported.
- P2 I/O pins read/written with 8086 IN/OUT instructions.
- A spare 8086 opcode is used to call P2 code.
My intention is to create a P2-DOS by getting open-source MS-DOS 2.11 to run on the P2. Progress on this has been rather slow, mainly because I don't actually enjoy writing 8086 code, but I see no reason why I could not work. I think having a "real" DOS with which many people are familiar would increase the P2's market appeal.
Writing the 8086 emulator was difficult and took a long time. I really cannot give it away for nothing but Parallax does not have any money to spare to buy this project off me and release it for free. I can't see how to resolve this quandary at the moment.
Comments
Sounds interesting, what sort of emulated speeds are you getting on the P2 running the 8086 instructions?
I've set certain input ports to read the P2 system count for measuring elapsed times, which makes timing instructions easy.
Slowest instructions relative to a real 8086 are arithmetic/logic with both operands registers. Equivalent 8086 clock = 7-10MHz with 250MHz sysclock. 8-bit slower than 16-bit due to the silly way Intel encoded 8-bit registers.
Anything with an effective address (EA) uses more P2 cycles but is relatively much quicker. Same applies to jumps and calls. Equivalent clock is 40-50, 70-80 or more than 100MHz.
NOP (aka XCHG AX,AX) takes 20 cycles (~38 MHz equivalent).
Here are some sample instruction timings:
P2 8086 Equiv. Comments cycles clocks MHz** ADC reg8,reg8 104 3 7 SBB is same ADD reg8,reg8 102 3 7 SUB is same ADC reg16,reg16 94 3 8 ADD reg16,reg16 92 3 8 INC reg16 64 2 8 DEC is same ADC AX,imm16 72 3 11 ADD AX,imm16 70 3 11 ADC reg16,[EA] 164-170 20 30 ADC [EA],reg16 167-173 27 40 ADC [EA],imm16 165-169 29 44 XCHG reg16,AX 20 3 38 NOP is same MOV reg8,imm8 20 4 50 MOV reg16,imm16 14 4 72 POP reg16 38 8 50 PUSH reg16 29-31 11 89 LOOP disp8 51/24 17/5 84/53 branch taken/not taken JMP disp8 45 15 84 JMP disp16 43 15 88 PUSHA* 51 36 178 80186 instruction POPA* 55 51 234 80186 instruction * registers pushed/popped in reverse order to real 80186+ ** Equiv. MHz is equivalent 8086/80186 clock for 252MHz P2 sysclk7-10MHz sounds pretty good if that's the slowest path, a classic 4.77MHz PC then seems potentially achievable on the P2 assuming the other parts of a basic system such as a keyboard and a display can eventually be adequately emulated too.
LOL, I'm imagining this anachronistic future where P2 dev tools that are stuck in PC world would run on an emulated PC running on the P2.
This is really exciting, well done TonyB
We still have a collection of dos stuff, because believe it or not we still have some automated test machines that still run dos and are still going strong. Xtree, gwbasic, qb45 etc...
Sample timings added to post 4 above. REPeated string instructions are much faster than a real 8086.
80186+ instructions emulated are PUSHA & POPA (in reversed order) and shifts/rotates with immediate. The latter took one extra long to do!
You might be able to fix this discrepancy by reversing your register storage order in COG RAM in case that helps.
Some thoughts on monetizing your effort:
1) Use something like Patreon to distribute copies for a subscription fee. This seems to work for Eric and FlexProp.
2) Offer subscriptions ... so much for a year or a major version ... so much for a specific # of months or a minor version.
3) Sell support per episode
To be honest... no, it doesn't work. Don't get me wrong, I appreciate very much the support of my patrons, and it does allow me to do things (like signing the Windows and MacOS binaries) that I wouldn't otherwise be able to do. But it's not yet a profit center, far from it. It seems the P2 market is not large enough yet to make any real money out of; or perhaps FlexProp just isn't a compelling product.
I think Tony might be better off creating some kind of hardware product (like a game emulator running 8086 games, or something like that) than on relying on P2 software sales.
I think the product is compelling. I think it's fantastic the little I get to do with it right at this moment. That will change, and I've been happy to toss my bit into the bucket.
I also think the P2 market is small right now. It took a while for the P1 to see growth, and once it did there were some products developed and successfully sold into it.
Finally, if I were Tony, I would research how the 8086 is being used today. If there are niches? A solid product replacement / addition is going to pay well, given there are real needs / risks to manage.
Seems to me, a PC-104 type board is gonna satisfy many niches. Those are 486 boards that can hit a few hundred Mhz. They will run DOS though I am not sure about the clock options. Retro people are building DOS gaming environments on them, making expansion backplanes and other thing to get back to an early PC sort of machine, but faster. These boards are not cheap.
For what it's worth, 6502's are still in use today. Many are just cores dropped into some other project, but actual 6502 chips do get used, and various emulators, tests, tools like the one linked here are used regularly. Not sure there is a profit in any of that, but there definitely is when it comes to physical products solving problems. It's still a thing, and perhaps that is true for the 8086.
And maybe the 8085?
That's a close, more simple target. One could emulate a TRS-80 Model 100 for reference. The 8085 saw a fair amount of specialized, embedded use. Maybe there is fertile ground there?
@TonyB_ Nice work !
I wish I had better ideas to contribute.
Unfortunately, you’re not likely to make any real money from anything here unless you hit a volume product. Even hardware has it’s problem unless you hit a commercial product.
Consider when you make a board, you need to buy in large quantities to keep the price down, so you end up with big inventories, and unused parts when the design moves on. Once you take this into account, it’s just like any other hobby - it costs you money. And this is without your time being included.
For example, my RetroBlade2 takes me a day (7.5 hrs) to build 15 boards - solder screen, place parts by hand, reflow solder (commercial machine), test and place in anti static bags ready to ship. This is spread over a couple of days because I cannot hand place more than about 10 boards at a time before my hand shakes. When I get an order for a board, I need to write out the address on a bag and pack a board or two, take it to the post office (30 min round trip plus 5-10 mins in the PO because my local PO loses product).
You can build and sell commercial products in small/medium/large volumes and make money - I’ve been doing that for 50 years - but commercial users will pay a reasonable price for a reasonable product. Cost rarely relates to physical product cost - it includes development time and software, etc. Hobbyists mostly want the product for nothing.
BTW I am not complaining, just stating reality. I do this as and for the hobby.
Maybe you could combine this with the legacy HW interface. I imagine a lot of old clunker systems are being kept around today only because of ancient HW that still needs its bus. eg. a setup using old 8 bit ISA cards you just can't put in other PC software emulators. If you could correctly emulate the ISA bus with additional COGs you might be able to build something useful to replace old HW not available anymore with something smaller/faster/more flexible.
I just counted 54 signals on an XT / 8 bit ISA bus. If the P2 fully emulated those with interrupts and DMA etc, that could leave 4 pins free for a PS/2 keyboard and an NTSC video output or monochrome video etc. You'd have the SD card to emulate a boot floppy or possibly flash/NVRAM to emulate a HDD, and the P2 serial port remaining for remote control/management potentially over a wireless interface. It's very bare bones but it might possibly be useful, or maybe just too niche.
Yes, I considered doing just that but it could require more longs (which might not be available as there is little free space left) and increase the timings of 8086 instructions (which I don't want to do, even if only by two cycles).
Although PUSHA & POPA are nice instructions to have, they are not part of the 8086 and would be the first things to go if more code were needed, for example for I/O or hardware interrupts. I'll look at it reversing the register storage again, however I don't think it's a real problem as it is now. In fact, pushing AX last could be an advantage for BIOS and DOS calls that return a value in AH or AL.
There are already x86 SoC on the market.
Do a 8051 (or AVR atmega328) emulator instead. This would probably make much more sense (and profit?).
@TonyB_ , another idea you could consider if you get desperately low on COG resources and eventually want to emulate more of a PC system would be to pair a second COG with your 8086 COG using LUT sharing. You could then bundle up and spill over some subset of the faster operations into the second COG's COGRAM for slower execution there instead, and data could be handed over via the LUT itself to save using any HUB RAM. It might be useful for this second COG to also do other things like act as an interrupt controller of sorts and then notify the main CPU core COG that some device/interrupt needs servicing via COGATN and/or via the LUTRAM mailbox. Maybe the normal PC timer and interrupt controller functionality and external DMA requests could be handled by this second COG to unburden the main CPU COG.
A lot of early DOS systems only used 512kB so it would be nice to be able to give them the full HUB memory (but that makes it harder to share data between COGs unless also done via this PC system memory). Edit: There's also probably the ROM BIOS stuff too to consider here which may eat into the 512kB unless it sits outside the P2.
Also if the emulated environment eventually provide an actual XT bus, you could put CGA cards into this too for genuine video output, or even just use a second P2 as the video controller device and couple it to the XT bus (with some 5V level translation). These approaches save all the memory in the core P2 as 512kB system memory, and it can provide more pins to the video output if done with a second P2. Eg. 8 pins for HDMI or 5 for RGBHV.
Thanks for the comments on how I might get some financial return. Creating a P2 8086 emulator needed someone to commit to it and I volunteered for the job. Now the really hard work has been done, I don't want to keep the result to myself but I don't have a paid job. I'd like to give some money to Eric for FlexSpin, which has been indispensable.
The main reason for doing the emulator was to allow the P2 to run a proper DOS, not to emulate the IBM PC and its various hardware devices on the P2. There is a fundamental difference between the two. To get DOS working, I need to write a BIOS which will be write-protected at the top of RAM probably and create IO.SYS. I have recreated MSDOS.SYS from the 2.11 source files. I can provide links to various DOS & BIOS resources if anyone is interested.
The 8086 emulator cog can handle the 18.2Hz timer interrupt itself (with 65536 ticks per hour) and I think this is the only essential interrupt for DOS. The emulator takes control of all 512K of hub RAM, with 16K reserved for the ROM BIOS (and P2 debugging) and another 16K for CGA video RAM at its usual address (which doesn't actually exist in the P2). Using low hub RAM for P2 parameters such as sysclock is not possible as this conflicts with the 8086 interrupt vector table.
The first version of DOS to run could be single-cog by using serial I/O. I hope a second cog would be enough for CGA-compatible video, keyboard and mouse.
Interesting. OK so no actual IO reads or writes, just DOS and BIOS INT calls. How have you planned to expand out the INT instruction? Does it branch out to call hub-exec code or something to notify another COG which will be performing the underlying I/O action or video change etc?
EDIT: just read this
I guess you can jump out from your interrupt handler in x86 code to P2 code this way.
I don't emulate any PC I/O ports. Hardware interrupts could be expanded by a paired cog writing the interrupt vector to shared LUT RAM or by reading the vector from hub RAM.