+- Freeplaytech Forum (https://forum.freeplaytech.com)
+-- Forum: Neo Geo Pocket (https://forum.freeplaytech.com/forumdisplay.php?fid=1)
+--- Forum: Homebrew (https://forum.freeplaytech.com/forumdisplay.php?fid=5)
+--- Thread: Data bus test (/showthread.php?tid=85)
Data bus test - mic_ - 10-20-2012
Download: ROM + source code
This is another test I've written that demonstrates the impact of utilizing memory in different ways.
The results will be printed in green if they match what I get on my NGPC +/- 1, and in red otherwise. Mednafen and NeoPop aren't even close.
Here are the correct results:
![[Image: ngp_bus.jpg]](http://jiggawatt.org/badc0de/other/ngp_bus.jpg)
Each test begins by syncing against timer0, and then starting the actual
test, which consists of a loop that increments a counter once every 50
states. This loop is allowed to run for approximately 12800 states, at which
point it will be aborted by the timer interrupt, and the value of the counter
is printed.
Two hexadecimal values are printed at each row. The first value shows the result
when using good code alignment for the TLCS-900/H, and the second value shows
the result when using poor code alignment.
Brief explanation of what each sub-test means:
ROM
The code is executed from ROM, and only performs register-internal operations, so
no memory access is done execpt for instruction fetching.
RAM
Same as the above, except that the code is executed from RAM, which makes code alignment
relevant since you want to avoid unaligned memory accesses on the 16-bit bus.
ROM+ROM
Executes from ROM, and does 32-bit reads from ROM.
RAM+ROM
Executes from RAM, and does 32-bit reads from ROM.
RAM+RAM
Executes from RAM, and does 32-bit reads from RAM.
T+Z TTS
The TLCS-900/H and Z80 are executing at the same time.
The TLCS-900/H executes from non-shared RAM ("TLCS" RAM) and does 32-bit reads from non-shared
RAM. The Z80 executes from and writes to shared RAM.
The line that says "Z80" shows the counter value obtained on the Z80 side, while the line that
says "TLCS" shows the counter value obtained on the TLCS-900/H side.
T+Z SSS
The TLCS-900/H and Z80 are executing at the same time.
The TLCS-900/H executes from shared RAM and does 32-bit reads from shared RAM.
The Z80 executes from and writes to shared RAM.
T+Z TSS
The TLCS-900/H and Z80 are executing at the same time.
The TLCS-900/H executes from non-shared RAM and does 32-bit reads from shared RAM.
The Z80 executes from and writes to shared RAM.
T+Z STS
The TLCS-900/H and Z80 are executing at the same time.
The TLCS-900/H executes from shared RAM and does 32-bit reads from non-shared RAM.
The Z80 executes from and writes to shared RAM.
T+Z R S
The TLCS-900/H and Z80 are executing at the same time.
The TLCS-900/H executes from ROM.
The Z80 executes from and writes to shared RAM.
RE: Data bus test - jdg - 10-24-2012
Cool, mess fails horribly too
RE: Data bus test - Cthulhu32 - 10-26-2012
Nice mic_. I'm working on porting RACE to DirectX/Win32 right now and trying to make it more modular, hoping to get a FlashMasta in late November for running real hardware tests like this. I'll release an initial version + src in the next few weeks, then hopefully start fixing all these TLCS900h discrepancies.
RE: Data bus test - mic_ - 10-26-2012
Does RACE have a debugger? That's something that would be really great: an reasonably accurate emulator with a debugger (disassembler with stepping and breakpoints, and a memory viewer are must-haves for a debugger; a VRAM viewer and I/O viewer would be nice-to-haves).
RE: Data bus test - Cthulhu32 - 10-26-2012
(10-26-2012, 03:26 AM)mic_ Wrote: Does RACE have a debugger? That's something that would be really great: an reasonably accurate emulator with a debugger (disassembler with stepping and breakpoints, and a memory viewer are must-haves for a debugger; a VRAM viewer and I/O viewer would be nice-to-haves).
Currently I don't see anything that is interactive in the source. You can dump the disassemble'd ops and output writes, but nothing like what FCEUX or Meka can do with breakpoints, VRAM outs, register/memory dumps. That's on my list of a "must-have" for this project, it would also help identify the current issues with the TLCS900h emulation right now.
Something I've been thinking about is how the debugger will handle running the tlcs900h and z80 side by side.
RE: Data bus test - mic_ - 10-26-2012
I've never looked at the RACE source code, but I'd imagine running the two processors in parallel when stepping in the debugger wouldn't differ much from running them in parallel during normal execution. It could affect performance of course, but if accuracy is the main goal then performance goes out the window right from the start anyway.
Not sure what a good-enough granularity would be for emulating the processors though. Maybe emulate 2 TLCS-900/H clock cycles, 1 Z80 clock cycle, 2 TLCS-900/H clock cycles, and so on. I think some NES emulators let the PPU be the "reference". So they emulate the PPU for N dots, then 1 CPU clock cycle.
RE: Data bus test - Flavor - 10-27-2012
RACE has no debugger. NeoPop does, though. I remember talking back and forth with NeoPopUK (the guy that made it) with suggestions and stuff about what to build into the debugger.
If I recall correctly, RACE has several speedup hacks, since it was targeted at running on handheld systems. I think the original code did 2 TLCS and then 1 Z80. We found that switching was time consuming, so I think maybe we put in some sort of functionality to do N TLCS and then N/2 Z80. I can't recall if N was variable or a #define.
Anyway, it wasn't like a thread for each. I think it's all a single thread.
RE: Data bus test - mic_ - 10-27-2012
Yeah, but NeoPop isn't accurate enough to run anything I've written correctly
