search

sy2002 / QNICE-FPGA

QNICE-FPGA is a 16-bit computer system for recreational programming built as a fully-fledged System-on-a-Chip in portable VHDL.
http://qnice-fpga.com
Other
69 stars 15 forks source link

Emulator's dump is not always showing the ASCII decoding #193

Closed sy2002 closed 3 years ago

sy2002 commented 3 years ago

Look at this dump command in the emulator:

[8F12] Q> dump $9107, $9110

9107: 0000 0030 0030 0030 0031 0000 0000 0000      0 0 0 1      
910f: 0000 0000

Everything is correct. 0x0030 is the hex representation of the ASCII value of the character 0 and 0x0031 of the character 1, so the 0 0 0 1 shown on the right side is correct.

Now look at this dump comand with a slightly modified start address compared to above:

[8F12] Q> dump $9108, $910f

9108: 0030 0030 0030 0031 0000 0000 0000 0000

The only difference to above is, that the first memory location has a value != 0 (i.e. 0x0030).

This (or some other obscure reason) leads to the emulator not printing the decoded 0 0 0 1 any more.

bernd-ulmann commented 3 years ago

I have problems reproducing this strange effect. I wrote a simple test program and loaded it into the emulator:

        .ORG    $8000
        HALT
        MOVE    R0, R0
        .ASCII_W    "0001"

Disassembling this, starting from various start addresses looks like this:

[0000] Q> load test.out
[0000] Q> dump 8000, 8020

1f40: 0000 0000 0000 0000 0000 0000 0000 0000
1f48: 0000 0000 0000 0000 0000 0000 0000 0000
1f50: 0000 0000 0000 0000 0000
[0000] Q> dump $8000,$8020

8000: e000 0000 0030 0030 0030 0031 0000 0000        0 0 0 1
8008: 0000 0000 0000 0000 0000 0000 0000 0000
8010: 0000 0000 0000 0000 0000 0000 0000 0000
8018: 0000 0000 0000 0000 0000 0000 0000 0000
8020: 0000
[0000] Q> dump $8001, $8020

8001: 0000 0030 0030 0030 0031 0000 0000 0000      0 0 0 1
8009: 0000 0000 0000 0000 0000 0000 0000 0000
8011: 0000 0000 0000 0000 0000 0000 0000 0000
8019: 0000 0000 0000 0000 0000 0000 0000 0000
[0000] Q> dump $8002, $8020

8002: 0030 0030 0030 0031 0000 0000 0000 0000    0 0 0 1
800a: 0000 0000 0000 0000 0000 0000 0000 0000
8012: 0000 0000 0000 0000 0000 0000 0000 0000
801a: 0000 0000 0000 0000 0000 0000 0000
[0000] Q> dump $8003, $8020

8003: 0030 0030 0031 0000 0000 0000 0000 0000    0 0 1
800b: 0000 0000 0000 0000 0000 0000 0000 0000
8013: 0000 0000 0000 0000 0000 0000 0000 0000
801b: 0000 0000 0000 0000 0000 0000

Which program did you load to trigger this behaviour? Maybe mine is too short?

sy2002 commented 3 years ago

Interessting Bug! :-)

I am currently developing tile_ed and there I can reproduce it. I played around a bit. Maybe it has more to do with the actual address that is being dumped than with the content of the address? I am reasoning this, because I have the strange effect, that it does not seem to depend on the content (0x0000 versus 0x0030) but maybe at the start and/or end address?

  1. If I go from $9114 to $911C then it does show the ASCII dump
  2. If I go from $9114 to $911A then it does not

Look at the screen:

grafik

I can reproduce it like this (you need to git pull the newest develop branch):

  1. For being on the safe side, go to tools and do a ./make-toolchain.sh (for having the newest monitor, etc.)

  2. Go to demos and do a ../assembler/asm tile_ed.asm

  3. Go to emulator and do ./make-vga.bash and then ./run-vga.bash

  4. Press CTRL+C in the serial window (that is the terminal window, the VGA window)

  5. Enter load ../demos/tile_ed.out

  6. Enter sb $8d8a

  7. Enter run $8000

  8. Switch to the VGA window and press F9 to enter palette the editing mode and then F3 and enter 1234 <Enter>. Then press F11 to go back and then F12 to start saving.

  9. Enter 1 <Enter> as "Project Description" and 2 <Enter> as "Element Identifier" and 3 <Enter> as Element comment.

  10. The breakpoint will be reached

  11. Switch to the "UART window" aka terminal window (the VGA window turns unresponsive during breakpoint, that is normal)

  12. Enter: dump $9114, $911C ==> works

  13. Enter: dump $9114, $911B ==> does not work

bernd-ulmann commented 3 years ago

Wow! That is strange. I could now reproduce it by changing the .ORG in the litte test program I posted to 0x9114. Issuing your exact dump commands shows the problem... I will take care of this now. :-)

bernd-ulmann commented 3 years ago

Solved... The easiest solution to fix this problem was to change the dump command so that it always dumps an integer multiple of eight words.