« previous next »
Pages: 1 2 [3]   Go Down

Author Topic: Low level hardware emulation  (Read 13836 times)

0 Members and 2 Guests are viewing this topic.

Offline AngelFish

  • Is this my custom title?
  • Administrator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3242
  • Rating: +270/-27
  • I'm a Fishbot
    • View Profile
Re: Low level hardware emulation
« Reply #30 on: March 21, 2011, 05:14:16 pm »
Quote from: calc84maniac on March 21, 2011, 05:08:57 pm
I wonder if it's recalculating 2^E each loop iteration?

It didn't go much faster when I explicitly defined the number of pixels and the Prizm does pretty well with math, so that's probably not it.

Also, there is a line drawing command, but it uses a line multiple pixels wide and you don't have pixel level control over it. It's like the [Thick] Line routine on the 8x series.
Logged
∂²Ψ    -(2m(V(x)-E)Ψ
---  = -------------
∂x²        ℏ²Ψ

Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Low level hardware emulation
« Reply #31 on: March 21, 2011, 09:28:17 pm »
How thick is the line? 3-5 pixels?  I wonder if there are any syscalls for lines.
Logged

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Low level hardware emulation
« Reply #32 on: March 22, 2011, 02:46:14 am »
Quote from: graphmastur on March 21, 2011, 02:37:35 pm
Err.. Working on a temporary assembler for Qwerty.55 before I can work on that.  And that reminds me.  Can anyone please explain how instructions that branch work.  I'm interested in calculating the displacements.  Qwerty.55 gave me some test code, but I still can't figure out how many bytes back stuff should be.  For example, what looks like it should be -6 bytes back is -4, or -5, or stuff like that.
Well time to test my knowledge on SH3. The reason why you probably got the wrong result is that because the SH3 has an execution pipeline that processes multiple instructions at once. When referencing the PC in an instruction, the PC is equal to the address of the current instruction plus 4. Also because the address of instructions is always a multiple of 2, the given address must be &'d with $FFFFFFFE. This ensures that the address is always even. And I believe you already know that when given a displacement you multiply that by 2.

And if I got this all wrong, that would explain why branching statements cause bugs right now on my emulator.  :P
Logged

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Low level hardware emulation
« Reply #33 on: March 22, 2011, 03:52:59 pm »
And it also explains why I still haven't figured it out.  Okay, so let me look....

So Qwerty.55 gave me this:
Code: [Select]
Loop:
   MOV.W @R1,R4
   ADD $FF,R1
   ADD $FF,R3
   TST R2,R2
   BF/S Loop
   MOV.W R4,@-R2
and said it compiled into:
Code: [Select]
   6411
   71FF
   73FF
   2228
   8FFA
   2245
The 8FFA being the BF/S statement.  So FA == -6 right?  So that's per instruction, meaning 12 bytes back, or 6 instructions back.  So, from the 6411 to the 8FFA is 8 bytes.  Okay, and 4 bytes ahead makes it 12.  I see.  Well that's not stupidly complicated.  I just kinda had to put that out there in writing and I guess it made sense.

I still don't see why you &'d $FFFFFFFE though.  Wouldn't it already be even no matter what?  Considering if you reference the number of instructions with displacements. IE. Function B references to go back to Function A.  Function A and B are both on an even displacement.  Function B references A, which is, let's say, 5 instructions back.  Since you multiply it by two to get the bytes, you always get an even number of bytes back, and instructions always start at even numbers.  So yeah, why did you & $FFFFFFFE?
Logged

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Low level hardware emulation
« Reply #34 on: March 23, 2011, 01:08:57 am »
@Graphmastur, that is because BSRF, JMP, and JSR use registers to find their address, meaning there is the possibility of an odd value being passed. But now that I think about that, the &ing with $FFFFFFFE is not needed to be done on an assembler. Only needed on disassemblers and emulators.

btw the way, how is progress going on your assembler. Because for me I'm starting to lose track of all my hex code and I don't think I'm ever going to figure out that Kpit GNU tools thing. I'd rather just use a command line assembler.
« Last Edit: March 23, 2011, 01:09:09 am by z80man »
Logged

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)

Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Low level hardware emulation
« Reply #35 on: March 23, 2011, 01:44:42 am »
Well, the temporary, ie not PrizmSuite, one is going well.  I'm trying to finish it asap.
Logged

Offline z80man

  • Casio Traitor
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 977
  • Rating: +85/-3
    • View Profile
Re: Low level hardware emulation
« Reply #36 on: March 23, 2011, 02:26:10 am »
Sounds good. Next week I have spring break and will have lots of time for coding. One thing that I want to make is an IDE designed for SH3 asm. Features I want to include are highlighting the word and long word sections for data and code, making it easier to set up displacements for jumps and MOV instructions. Also I want to do warnings for when the label used in an instruction is out of range, an illegal instruction is used (such as if a jump is used after a delayed branch), and when two instructions that when used in tandem will take extra clock cycles (such as accessing the MAC after a multiply instruction or using a register that was written to from memory in the last instruction). And just maybe some support on doing self-modifying code.  ;)
Logged

List of stuff I need to do before September:
1. Finish the Emulator of the Casio Prizm (in active development)
2. Finish the the SH3 asm IDE/assembler/linker program (in active development)
3. Create a partial Java virtual machine  for the Prizm (not started)
4. Create Axe for the Prizm with an Axe legacy mode (in planning phase)
5. Develop a large set of C and asm libraries for the Prizm (some progress)
6. Create an emulator of the 83+ for the Prizm (not started)
7. Create a well polished game that showcases the ability of the Casio Prizm (not started)
Pages: 1 2 [3]   Go Up
« previous next »