Issue with as86/ld86 and ORG

[earlz]

I also think I'm seeing an issue with eIP getting off by one after an IRET. I need to look into it more, but it seems like after I handle an interrupt I get a bunch of garbage instructions until the CPU crashes.

Edit: I take that back, it seems to be fine after IRET, somewhere the IP is getting off though...

Edit2: I think I found whats happening.

In the ASM I have a JMP to address 0x0BDC

After executing the instruction, eIP is 0xBDB so I guess we're subtracting when we shouldnt?


Ok, here's the instruction that it's having issues with

Opcode: E97500

According to microsoft's debug this is a JMP 0BDC
current eIP is 0x0B64

So, 0x75 is our offset to the next instruction, 0x0B64 + 0x75 gives us 0xBD9

In jmp16_near16 we do the add, then ++ eip, so now we're at 0xBDA. Next cycle goes around, add 1, we have 0xBDB, we need +1 to get to the right instruction at 0xBDC

Now I know that Jmp16_near16 happens all the time so why is it this one time it's messing up? The actual assembly is just a Jump to a label so it shouldn't be that big of a deal...

E9 7500

would be jump EIP+0x0075.. hmm..

well, I must ask. Why are you using a rel16 jmp when it will fit in a rel8? assembler bug? lol

but I'm trying to duplicate this bug, I think adding a simple eip++ fixes it. Maybe the reason it has gone unnoticed is because rel8 is usually used and the rm/16 and such jmp functions don't use the relative code I have.

one question. Have you any idea what a jmp relative 0 would do? would it jmp ahead none and therefore just go to the next instruction? or would it cause an infinite loop? hmm..

[myk]

That's a good question, I have no idea.

Yea whatever the jump instruction there is is whatever the assembler gave me

[earlz]

That's a good question, I have no idea.

Yea whatever the jump instruction there is is whatever the assembler gave me

Ok, that jmp problem and the IVT issue is both fixed in this latest commit. And those MemoryDevice and such classes are not used yet, so don't get too excited lol

[myk]

haha, no prob, i just want to get this keyboard controller functional

[earlz]

Well.. this memory and port device system might take a few days.. It's all modularized, so switching from the old to the new system is a breeze. But actually implementing this new system will take quite a bit of work because of edge cases and lots of checks between different memory/port ranges.. ugh..

[myk]

Sweet, take your time I'll just try to get some stuff going on this end. Btw, I think some of the eip++ changes you made might have borked something lol, it doesn't appear to work now. I'm trying to track down where it breaks. Is there anything I can get you to help debug?

[earlz]

Sweet, take your time I'll just try to get some stuff going on this end. Btw, I think some of the eip++ changes you made might have borked something lol, it doesn't appear to work now. I'm trying to track down where it breaks. Is there anything I can get you to help debug?

well your emulator source would of course help. lol.

if you can find the faulty opcode it would also help(like the jmp opcode in what syntax)

I have quite a bit of test code and it works here.. so I really don't know. You did revert you hack around changes to the IVT in your source right?

edit:
Ok, I think I found it. loop_rel8 was incrementing eip one too many times. so this latest revision should have the fix.

[myk]

Yea, i need to get you a copy of my source, should I just email it too you?

Also, just tried a program I wrote for the 8086 that was written in asm + c and it's pretty much working! For some strange reason the eIP is getting messed up after calling CheckInterrupts() but that's all I've looked into so far. I'll try your newest code

Let me know how I should get that too you!

Edit: Oh duh! I forgot I had my LED write code hacked to cause a keyboard interrupt and it was interrupting when I wrote to the LEDs in my C code program and I hadn't initiated the IVT so it just went to a crazy addr.

[earlz]

Yea, i need to get you a copy of my source, should I just email it too you?

Also, just tried a program I wrote for the 8086 that was written in asm + c and it's pretty much working! For some strange reason the eIP is getting messed up after calling CheckInterrupts() but that's all I've looked into so far. I'll try your newest code

Let me know how I should get that too you!

Edit: Oh duh! I forgot I had my LED write code hacked to cause a keyboard interrupt and it was interrupting when I wrote to the LEDs in my C code program and I hadn't initiated the IVT so it just went to a crazy addr.

lol nice. and yea. I can set you up a separate SVN on my server and maybe I can get a compiler going on windows to test things... just email me the source or if you want your own SVN repo..

[myk]

SVN would be nice. I'm actually working on a mac so if you've got a linux setup going then it should be really easy to get everything going I would assume.

[earlz]

SVN would be nice. I'm actually working on a mac so if you've got a linux setup going then it should be really easy to get everything going I would assume.

I sent you an email...

[myk]

Just to correct something I said earlier, the reset address is

CS: 0xF000
IP: 0xFFF0

not

CS: 0xF000
IP: 0xFFFE

I'm not sure why I was thinking of that, but it's definitely 0xFFFF0

[jal]

I'm not sure why I was thinking of that, but it's definitely 0xFFFF0

FFFE wouldn't leave room for a far jump instruction, so it wouldn't make sense if it was :).


JAL

[earlz]

I'm not sure why I was thinking of that, but it's definitely 0xFFFF0

FFFE wouldn't leave room for a far jump instruction, so it wouldn't make sense if it was .


JAL

true, but what I did was just insert two nops at 0xFFFE and 0xFFFF so it rolls over to 0x0000... lol

It should be fixed in SVN now though(as of last night)

[myk]

Here's a quick little video of the program in action.


If you want to see the original in action:


Hmm, not sure if that actually worked... Here's the links:
http://www.youtube.com/watch?v=A90_V2VUr1A
http://www.youtube.com/watch?v=bhv8hGZ2fSQ