 No.06077
Tafoid Administrator
May 10, 2010, 21:04
|
There is a shifting of your input (by x8). This might or might not be by design - I'll leave this open to have Aaron or someone else familiar to the CPU to comment. |
|---|---|
 No.06078
Haze Senior Tester
May 10, 2010, 22:54
|
I seem to remember the TMS can address in bits, rather than bytes... (correct me if I'm wrong, but that would explain ths shifting) |
|
No.06105
Luigi30 Tester
May 13, 2010, 01:35
edited on: May 13, 2010, 01:48
|
Memory searches don't work either. Even if I search for a word that's showing in the debugger at the location in the program it always reports no results. Memory dumps are 1/8 the size you specify, too. There's a stray 8 somewhere in the 34010 debugger code. |
|
No.06106
Haze Senior Tester
May 13, 2010, 03:03
|
As I said, I think it's somewhat intentional, the addresses are in *bits*, not *bytes* |
|
No.06107
Luigi30 Tester
May 13, 2010, 03:43
edited on: May 13, 2010, 03:44
|
It's inconsistent, though. The "save" command works at the address specified (if you give it FF800000, you get memory starting at FF800000), but it saves 1/8 the memory you want. The memory window multiplies your address by 8 before jumping to it. I don't think you're supposed to have to guess whether it wants a number, a number multiplied by 8, or a number divided by 8 when entering a debugger command. |
|
No.06120
couriersud Developer
May 16, 2010, 00:22
edited on: May 16, 2010, 00:25
|
Within the tms34010 core, an "address" is not identical to a "byte-position". Memory at byte offset 2 is at "address" 0x10 and memory at offset 0x80 is at "adress" 0x400. I have fixed the memory window issue now. This was indeed a bug. Entering "curpc" would not work. The save is just intended functionality. Saving "addresses" from 0x0000 to 0x0400 will save a range of 0x80 bytes. The whole behaviour is governed by: case DEVINFO_INT_ADDRBUS_SHIFT + ADDRESS_SPACE_PROGRAM: info->i = 3; break; in tms34010.c I left the status on "direction needed" since it is a somewhat philosophical question whether the debugger should work on byte offsets or on "addresses" as implied by the cpu model. Both approaches have pros and cons, no free lunch. |
|
No.06121
Luigi30 Tester
May 16, 2010, 17:17
|
Either way if you want to save a memory region of length 400000 at FF800000, MAME doesn't know the difference and won't let you save it if you put in 2000000 (400000 * 8). It just saves a 0-byte file since it thinks the length is invalid. |
|
No.06123
couriersud Developer
May 16, 2010, 18:03
edited on: May 16, 2010, 18:03
|
Hmm, "dump t.dmp,FF800000,800000" will dump from FF800000 to FFFFFFFF and "dump t.dmp,FF800000,400000" will dump from FF800000 to FFBFFFFF Since the lower three bits *may* be used to address individuals bits, 16 bytes of memory translate into address increments of 0x80 (0x10<<3) in the dump file. Whats wrong here? |
|
No.06124
Luigi30 Tester
May 16, 2010, 18:14
edited on: May 16, 2010, 18:14
|
I was getting confused. The dump file increments each line by 80 while my hex editor counts each line of the sav file by 10. |
|
No.06180
couriersud Developer
May 25, 2010, 22:07
|
The issue is now fixed. Any discussion on general address handling should be taken to the list. |