Page 5 of 11
Re: Dragon emulator written in Python ???
Posted: Mon Oct 07, 2013 6:27 pm
by jedie
So, i split and refactor many stuff:
https://github.com/jedie/DragonPy/compa ... ...4fd0e4b
Now it's callable in this way:
DragonPy$ ./DragonPy_CLI.py --cfg Simple6809Cfg --verbosity=5
or:
DragonPy$ ./DragonPy_CLI.py --cfg Dragon32Cfg --verbosity=5
But there are a few OPs unimplemented for the Simple6809 ROM
Re: Dragon emulator written in Python ???
Posted: Mon Oct 07, 2013 11:01 pm
by JeeK
jedie wrote:
[..]
You can see: LDA #-128 and SUBA #1 results in accu A == $7f == signed: 127 == unsigned: 127
Flags set to:
N= 0
Z= 0
V= 1
C= 0
Second one LDA #+127 and ADDA #1 results in accu A == $80 == signed: -128 == unsigned: 128
Flags set to:
N= 1
Z= 0
V= 1
C= 0
Is that right?
Seems right so far.
jedie wrote:
Have you a example for Carry and Half-Carry?
Carry should be easy, every arithmetic operation which lead to value > $FF or shift/rotate operation which moves
bit 0 or 7 in the C flag.
Half-Carry: like the carry for 8 bits of a register, imagine the register is sized to 4 bits only. Transitions from bit 3 (counting from 0) to bit 4 on arithmetic operations are reflected in the half carry flag. I'm not sure about ASL (same opcode is LSL) other shift/rotate ops if they are really effecting the H flag.
Labiak says not effected by LSR/ASR, NEG, SBC, INC..., but on my simulator some of them do effect H (maybe wrongly). Can't prove it on a real 6809 at the moment, Xroar should it do correct too.
At least ADD/ADC is supposed to do so:
Code: Select all
lda #$0e
adda #1 ; gives $0F C=0, V=0, N=0, Z=0, H=0!
adda #1 ; gives $10 C=0, V=0, N=0, Z=0, H=1
SBC, SUB should effect H also because it does an addition just with a negated operand, but didn't prove it, Labiak says "unpredicted". I doubt that.
Re: Dragon emulator written in Python ???
Posted: Tue Oct 08, 2013 6:52 am
by sixxie
JeeK wrote:
SBC, SUB should effect H also because it does an addition just with a negated operand, but didn't prove it, Labiak says "unpredicted". I doubt that.
Good point! That's something I either haven't tested or did test but stupidly didn't write down. Doubtless the H output from the ALU will have some predictable value, but it is possible that it doesn't then get latched to the appropriate CC bit for the subtract instructions. That needs a good testing, that does.
Re: Dragon emulator written in Python ???
Posted: Tue Oct 08, 2013 8:46 am
by jedie
Sarah wrote:Set mapmode0 and reinstate the mapmode0 ROM.
Ah, now I have found an explanation in the Inside The Dragon book in "Appendix 5 - The Dragon 64 / SWITCHING IN RAM"... But ok, that is still too far away.
Now i would like to implement all for a working Simple6809 setup... If i really accomplished, I'm very glad!
Then I can continue with Dragon 32... And maybe then Dragon 64. But, do not know if that's really realistic.
We have XRoar, a really good emulator. It makes no sense to implement a second XRoar in python.
The sense of the project is more to learn and understand than to have a second XRoar
In the far future i would like to implement a integrated development environment for BASIC programs. Similar to the Rainbow IDE:
A running Emulator instance with beside a simple text editor. The editor content would be synced with the emulated RAM. So you can simply type a BASIC Programm and click on a "run" button to see the results.
Now i do the same with XRoar: Open a text editor, save into .bas and use XRoar "run" menu point.
Maybe i will start with the IDE, if i get Simple6809 to run.
Re: Dragon emulator written in Python ???
Posted: Wed Oct 09, 2013 1:58 pm
by jedie
Next Question:
| 08 0008 | LSL/ASL | DIRECT | 6 | 2 | naaas |
| 24 0036 | BHS/BCC | RELATIVE | 3 | 2 | ----- |
| 25 0037 | BLO/BCS | RELATIVE | 3 | 2 | ----- |
| 48 0072 | LSLA/ASLA | INHERENT | 2 | 1 | naaas |
| 58 0088 | LSLB/ASLB | INHERENT | 2 | 1 | naaas |
| 68 0104 | LSL/ASL | INDEXED | 6 | 2 | naaas |
| 78 0120 | LSL/ASL | EXTENDED | 7 | 3 | naaas |
| 1024 4132 | LBHS/LBCC | RELATIVE | 5(6) | 4 | ----- |
| 1025 4133 | LBLO/LBCS | RELATIVE | 5(6) | 4 | ----- |
Why are theses ops "two ops" ?
e.g.:
LSL = Logical shift left
ASL = Arithmetic shift left
In one description for LSL have i found this:
This is a duplicate assembly-language mnemonic for the single machine instruction ASL.
So i think this is only relevant for a assembler, but not for a disassembler and not for a emulator, isn't it?
Re: Dragon emulator written in Python ???
Posted: Wed Oct 09, 2013 3:14 pm
by Sarah
The mnemonics are duplicated for convenience; if they actually existed as separate opcodes then both instructions in each pair would do exactly the same thing.
For example, if you're shifting left then logical shifts are the same as arithmetic shifts, unlike when you shift right. The branch operations like BHS and BCC can be easier to understand as either "branch higher or same" or "branch C clear" depending upon the context or person, even though they're identical conditions.
Re: Dragon emulator written in Python ???
Posted: Wed Oct 09, 2013 3:27 pm
by jedie
I've also interpreted.
Thanks for the confirmation.
Re: Dragon emulator written in Python ???
Posted: Wed Oct 09, 2013 5:08 pm
by jedie
Have made a big code change... Because i saw that i mismatch ea/m and byte/word
Updated "6809 data script" ->
https://github.com/jedie/DragonPy/commi ... a7b0cea194
Updated CPU code ->
https://github.com/jedie/DragonPy/commi ... 8f6baac6f1
Re: Dragon emulator written in Python ???
Posted: Wed Oct 09, 2013 10:20 pm
by jedie
Simple6809 ROM started to work... RAM Test seems to work:
Code: Select all
$ ./DragonPy_CLI.py --cfg Simple6809Cfg --verbosity=30 --area_debug=5:db80-ffff
logger name: DragonPy
DragonPy - Dragon 32 emulator in Python None
-------------------------------------------------------------------------------
set log level to: 20
Activate area debug: Set debug level to 5 from $db80 to $ffff
Startup CPU with: /usr/bin/python cpu6809.py --bus_socket_host=127.0.0.1 --bus_socket_port=51355 --cfg Simple6809Cfg --verbosity=30 --area_debug=5:db80-ffff
logger name: DragonPy
DragonPy - Dragon 32 emulator in Python None
-------------------------------------------------------------------------------
set log level to: 20
Activate area debug: Set debug level to 5 from $db80 to $ffff
Connect to internal socket bus I/O ('127.0.0.1', 51355)
CPU started
reading outside memory area (PC:$db6c): $7fff
reading outside memory area (PC:$db6f): $7fff
writing outside memory area (PC:$db6f): $7fff
reading outside memory area (PC:$db71): $7fff
Activate area debug at $db80
$db7f 30 LEAX register:<X (16-Bit):$7ffd> ea:$7f35 | None
$0021 9F STX register:<X (16-Bit):$7f35> ea:$21 m:$0 | None
$db86 1F TFR ea:$db86 m:$14 | None
$db88 8E LDX register:<X (16-Bit):$7f35> ea:$db88 m:$dbce | None
$db8b CE LDU register:<U (16-Bit):$0000> ea:$db8b m:$76 | None
$db8e C6 LDB register:<B (8-Bit):$00> ea:$db8e m:$12 | None
$db8f BD JSR ea:$dcae | None
$dbcf A6 LDA register:<A (8-Bit):$ff> ea:$dbcf m:$40 | None
...
Re: Dragon emulator written in Python ???
Posted: Thu Oct 10, 2013 12:01 pm
by jedie
xroar -trace is great. I tweak the DragonPy debug output with
--verbosity=20 to a similar format.
xraor:
Code: Select all
fffe| b3b4 [RESET]
b3b4| 318ce4 LEAY -$1c,PCR cc=50 a=00 b=00 dp=00 x=0000 y=b39b u=0000 s=0000
b3b7| 7e8000 JMP $8000 cc=50 a=00 b=00 dp=00 x=0000 y=b39b u=0000 s=0000
8000| 7ebb40 JMP $bb40 cc=50 a=00 b=00 dp=00 x=0000 y=b39b u=0000 s=0000
bb40| cc0034 LDD #$0034 cc=50 a=00 b=34 dp=00 x=0000 y=b39b u=0000 s=0000
bb43| 8eff00 LDX #$ff00 cc=58 a=00 b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
bb46| a701 STA 1,X cc=54 a=00 b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
bb48| a703 STA 3,X cc=54 a=00 b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
bb4a| a784 STA ,X cc=54 a=00 b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
bb4c| 43 COMA cc=59 a=ff b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
bb4d| a702 STA 2,X cc=59 a=ff b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
bb4f| e701 STB 1,X cc=51 a=ff b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
bb51| e703 STB 3,X cc=51 a=ff b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
bb53| 8eff20 LDX #$ff20 cc=59 a=ff b=34 dp=00 x=ff20 y=b39b u=0000 s=0000
bb56| 6f01 CLR 1,X cc=54 a=ff b=34 dp=00 x=ff20 y=b39b u=0000 s=0000
bb58| 6f03 CLR 3,X cc=54 a=ff b=34 dp=00 x=ff20 y=b39b u=0000 s=0000
bb5a| 4a DECA cc=58 a=fe b=34 dp=00 x=ff20 y=b39b u=0000 s=0000
...
DragonPy:
Code: Select all
$b3b4 31 LEAY register:Y=0000 ea:$b39b | cc=50 a=00 b=00 dp=00 x=0000 y=b39b u=0000 s=0000
$b3b7 7E JMP ea:$8000 | cc=50 a=00 b=00 dp=00 x=0000 y=b39b u=0000 s=0000
$8000 7E JMP ea:$bb40 | cc=50 a=00 b=00 dp=00 x=0000 y=b39b u=0000 s=0000
$bb41 CC LDD register:D=0000 ea:$bb41 m:$34 | cc=50 a=00 b=34 dp=00 x=0000 y=b39b u=0000 s=0000
$bb44 8E LDX register:X=0000 ea:$bb44 m:$ff00 | cc=58 a=00 b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
$ff01 A7 STA register:A=00 ea:$ff01 m:$b3 | cc=50 a=00 b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
$ff03 A7 STA register:A=00 ea:$ff03 m:$35 | cc=50 a=00 b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
$ff00 A7 STA register:A=00 ea:$ff00 m:$0 | cc=54 a=00 b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
$bb4c 43 COMA register:A=00 | cc=59 a=ff b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
$ff02 A7 STA register:A=ff ea:$ff02 m:$0 | cc=51 a=ff b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
$ff01 E7 STB register:B=34 ea:$ff01 m:$b3 | cc=51 a=ff b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
$ff03 E7 STB register:B=34 ea:$ff03 m:$35 | cc=51 a=ff b=34 dp=00 x=ff00 y=b39b u=0000 s=0000
$bb54 8E LDX register:X=ff00 ea:$bb54 m:$ff20 | cc=59 a=ff b=34 dp=00 x=ff20 y=b39b u=0000 s=0000
$ff21 6F CLR ea:$ff21 m:$34 | cc=54 a=ff b=34 dp=00 x=ff20 y=b39b u=0000 s=0000
$ff23 6F CLR ea:$ff23 m:$37 | cc=54 a=ff b=34 dp=00 x=ff20 y=b39b u=0000 s=0000
$bb5a 4A DECA register:A=ff | cc=58 a=fe b=34 dp=00 x=ff20 y=b39b u=0000 s=0000
...
And we see here, that the CC registers has bugs in DragonPy