OSDev.org

Owen wrote:"What bus does it use?"
I'd guess, given that it's based upon the 8086, that it would use the 8086 bus...

I was thinking more along the lines of ISA, PCI etc.


JAL

jal wrote:

Owen wrote:"What bus does it use?"
I'd guess, given that it's based upon the 8086, that it would use the 8086 bus...

I was thinking more along the lines of ISA, PCI etc.


JAL

my guess would be it doesn't have any bus in that sort, probably just hacked together stuff working off a multiplexer and the IO ports of the 8086

Oops! I forgot to check this thread, sorry about the late reply. Yes, the 8086 is very basic and it just has a 16 bit data bus and a 20 bit address bus. It does have an interrupt controller, I forget the # but everything about the project should be in the files I uploaded. It also has a hardware UART so it can be controlled from a computer using a terminal emulator. It also has a two GAL 22v10d's (After 4 years I still remember that part #) that control chip selects based upon the bus address. If I remember right, the LEDs are mapped to the segment 0x3000 in the memory map. So any address in the 0x3000 range will allow you to write to the LEDs. It's rather wasteful allocating 64k of the memmap to just a 16 bit device, but it was a trade off that I made since the board didn't need to support a huge number of external devices.

I'm happy to answer any questions about this. I recently contacted my old professor about this project hoping to help write a book/manual for his comp arch class. He approached us about writing a book about 8086 hardware and software design back in the day but I had no time to work on it then. I'd love to release it as an open license so others could learn so any questions you have about the hardware or software I will try to answer. I can probably give you much better answers now. SInce graduating and working as a software engineer for two years, my skill in low level development has improved a LOT!

With the Chip Select GAL devices, I believe that I only checked the top 4 bits of the address (first 4 bits of the segment). This is why, according to the GAL, that the addresses 0x30000, 0x30002, 0x30004, etc are all the same, it only checks the first 4 bits (the 0x3) and enables a chip based upon that.

The trade off was complexity of wiring the GAL, it only needed 4 address lines instead of 19. It could have been wired to use A19-A1 so that:

0x30000 : LED Data
0x30002 : LCD Command
0x30004 : LCD Data
0x30006 : UART Command
0x30008 : UART Data

But that would have been a lot of extra wires and I don't believe my GAL had enough I/O capable pins to make this work.

ugh.. I so need more electronic stuff.. I really want to create some simple computer, even if its a hacked up ARM or something else "easy" to find..

seems like a high investment though, and my electronic knowledge is so very low.. (*note to self, get in some electronic college courses lol)

I have four 80186 lying around, I would love to put them to use somehow, but there's no chance on earth since I don't know anything about hardware, unfortunately. @myk: thanks for the interesting stories!


JAL

Unfortunately there is a somewhat high up front cost when developing any hardware, this project definitely has a lot up front. Just to develop efficiently, you need some way of emulating your ROMs. The hardware to do that can cost a few hundred dollars (or you can build it yourself for around 30-50ish).

If you are interested in computer architecture I highly recommend The Intel Microprocessors by Barry Brey, it's full of easy to read schematics.

Last night I started playing with x86Lib. Very nice I must say. I put one of my old binaries from school as the bios.bin file and hacked around in the WriteByte stuff to catch everything going to location 0x50002 and print it to the console (this is the address for the LCD data) and it actually prints out the bootup memtest message before it causes the cpu to panic during the memtest (I'm sure I have something setup wrong).

I think I'm going to make a little Qt app that displays a 4x20 character LCD and I'll hook that into the WriteByte so I can emulate the LCD. 0x50000 is the LCD Command address so I'd have to emulate that as well but it shouldn't be too difficult. Might be a nice weekend project. If I can get this thing going nicely I'll have to forward it onto my old professor and maybe he can use it for class.

About the dev tools I was using before, I scrapped them in favor of some old Intel toolchain I found that works perfectly. So far I've just dink-ed around with some asm bootup code to C and after inspecting the binary coming from the locator it looks like everything is working perfectly. I'm very excited! Once I get it going, I'll post a little tutorial how to write your own startup ROM.

Speaking of bootup code, I'm wondering why the x86Lib doesn't start with CS:IP at 0xF000:0xFFFE? That's technically the x86 reset address. It currently starts at 0xF000:0x0000 which works due to how my ROM is setup, but if someone has data other than the executable at location 0 of their ROM it will be executed as code.

myk wrote:Last night I started playing with x86Lib. Very nice I must say. I put one of my old binaries from school as the bios.bin file and hacked around in the WriteByte stuff to catch everything going to location 0x50002 and print it to the console (this is the address for the LCD data) and it actually prints out the bootup memtest message before it causes the cpu to panic during the memtest (I'm sure I have something setup wrong).

I think I'm going to make a little Qt app that displays a 4x20 character LCD and I'll hook that into the WriteByte so I can emulate the LCD. 0x50000 is the LCD Command address so I'd have to emulate that as well but it shouldn't be too difficult. Might be a nice weekend project. If I can get this thing going nicely I'll have to forward it onto my old professor and maybe he can use it for class.

About the dev tools I was using before, I scrapped them in favor of some old Intel toolchain I found that works perfectly. So far I've just dink-ed around with some asm bootup code to C and after inspecting the binary coming from the locator it looks like everything is working perfectly. I'm very excited! Once I get it going, I'll post a little tutorial how to write your own startup ROM.

Speaking of bootup code, I'm wondering why the x86Lib doesn't start with CS:IP at 0xF000:0xFFFE? That's technically the x86 reset address. It currently starts at 0xF000:0x0000 which works due to how my ROM is setup, but if someone has data other than the executable at location 0 of their ROM it will be executed as code.

Well, I wasn't actually for sure what the official startup address was. I can change that very quickly, as I wasn't aware there was an official one(so I just used the BIOS reset address).

man.. well you working with this inspires me to work on it a bit and see if I can get a new version out with a few fixed bugs(I know there were a few to do with segment checking)

nice to know someone's using my project!

Well thanks for making it available, it was pretty simple to get up and running! I am running into this

CPU Panic!
Message: 16bit Faults
Code: 0x1f006

that I'm trying to track down. It's either an issue with how I've got things configured (I think all I did was change the ROM_ADDRESS) or a bug with in the library. I'm running code that I know works on hardware.

Here's my current output

The LCD Command output is some stuff I put in there to hijack all writes to 0x50000. These commands are for a SPLC780C LCD controller.
The text "Physical Memory Test" is output to the LCD that get's written to 0x50002, I just redirect it to the command line at the moment.

The code that it's died on is here:

http://code.google.com/p/romulatoravr/s ... M/Proc.asm
This is currently being executed fine (the s_mem_check is the Physical Memory Test string).

It's just somewhere after that where the problem happens.

It looks like it's happening right after the CLI instruction in the code I posted. The instruction right after it should be PUSH ES but instead the next opcode that the library executes is rep().

Edit: I just noticed that it's hitting the unknown_op function... something must not be getting read correctly.

thats a list of exception codes I should have long ago published.

Your getting an unknown opcode(as you discovered)

Are you relying on segment overflow? (Like jump to 0xFFFE and assume it eventually gets back to 0x0000) cause if so I just committed some code fixing that problem and also that changes the initial start address to 0xF000:FFFE

I'll look through your code and see anything that might look a bit tricky

The Opcode it's choking on is 0xAB (STOSW). According to the debugger built into windows (debug at the command prompt) this is what is happening:
I would attach the binary but the forum wont let me attach it... even if I change the file extension...


Edit: There we go, change from txt to bin

myk wrote:The Opcode it's choking on is 0xAB (STOSW). According to the debugger built into windows (debug at the command prompt) this is what is happening:

Code: Select all

Addr     Opcode      Instruction
0032:    B85555     MOV AX, 5555
0035:    B9FFFF     MOV CX, FFFF
0038:    FC            CLD
0039:    FA            CLI
003A:    F3            REPZ
0003B:   AB           STOSW <- Invalid Instruction

holy crap! I'm missing an opcode lol

Guess I didn't have 8086 support in all the way. (Must've been missed in my scanning of opcodes for only the 8086)

I'll add the STOSB and STOSW instructions to it and post back here..

[edit]

You are using my latest SVN version right? if your not, then it's pretty simple. just check it out and then type `make` and it'll build the library and test file..

ok ok..

I added those simple two instructions, so now it should work..