Menu
▾
▴
8 Attachments
#4068 uCsim issue with huc6280
uCsim has issues when using -t6280
many simulations fail with stack overflow.
attached files are from plain mos6502 build which should work unchanged on huc6280
uCsim commands:
set error stack on
set hw simif rom 0xfff0
step 500000000 vclk
state
gorlik@a64:/mnt/scratch/build/sdcc/sdcc-svnt/sdcc/support/regression$ ../../sim/ucsim/src/sims/mos6502.src/ucsim_mos6502 -t6502 gen/uc6502/tst_bug-2357.ihx
uCsim 0.9.9, Copyright (C) 1997 Daniel Drotos.
uCsim comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
0> 1395 words read from gen/uc6502/tst_bug-2357.ihx
set error stack on
set hw simif rom 0xfff0
step 500000000 vclk
state0> 0> --- Running: bug-2357.c
Running testBug
--- Summary: 0/4/1: 0 failed of 4 tests in 1 cases.
Stop at 0x0004ec: (110) Program stopped itself
F 0x0004ec
Simulated 18936 ticks (1.894e-02 sec)
Host usage: 0.002859 sec, rate=6.623027
0>
gorlik@a64:/mnt/scratch/build/sdcc/sdcc-svnt/sdcc/support/regression$ ../../sim/ucsim/src/sims/mos6502.src/ucsim_mos6502 -t6280 gen/uc6502/tst_bug-2357.ihx
uCsim 0.9.9, Copyright (C) 1997 Daniel Drotos.
uCsim comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
0> 1395 words read from gen/uc6502/tst_bug-2357.ihx
set error stack on
set hw simif rom 0xfff0
step 500000000 vclk
state0> 0> Stack overflow, PC=0x0
Stop at 0x000320: (108) F 0x000320
Simulated 10 ticks (1.000e-05 sec)
Host usage: 0.000044 sec, rate=0.226719
0>
Diff:
Could it be that the reset() method of class cl_huc6280 should have called the cl_mos6502::reset() method instead of the cl_uc::reset() as the one in cl_mos6502 set the stack pointer? The processor is an extended WDC 65C02, which class inherits the mos6502 class, hence also it's reset() method.
I do not have a working environment so I cannot test.
Patch to this effect, attached
[r16843]
Related
Commit: [r16843]
many tests still fail when -t6280 is passed to the simulator.
changing
EMU_PORT_FLAG=-t65c02toEMU_PORT_FLAG=-t6280inports/uc6280/spec.mkproduces:
It seem some files fail to load properly when the
-t6280flag is set.Referring to the attached files:
the reset vector is wrong in the huc6280 case.
6280 harware document:
This means that 6502 and 6280 use different memory layout which can be a problem for bigger programs. I can setup MPR regs to emulate a 6502's 64k system, but it will not be true for the real CPU.
Daniel
thanks for the reply.
I suspected the issue was due to the MPR mapping but that is inconsistent with two observations:
stateright after loading shows PC = 0x2251 which is the value at 0xfffcI am not sure exactly what is the issue, but something is wrong (I don't exclude the crt0).
As the address space is mapped as 8k chunks, smaller programs will succseed, biggers will fail.
I can init map registers to emulate 64k system, but there is an other problem, the doc says:
So if a program is bigger than 0x2100, it will still fail, bc the stack will overwrite the code.
I've made high half of SP configurable, so you can create a non-real 6280 which uses the memory the same way as 6502 does:
All tests will pass with that setting:
Just an outside opinion, but I feel like the simulator should behave as close to the hardware as it reasonably can, so we can be confident that what passes the regression tests would also work on real hardware (naturally this might exclude the channel we use for communicating with the regression test infrastructure). So if programs needs some registers set up a certain way, it would be the job of the crt0 to do so (unless the real hardware does initialize them).
Understand your opinion, and I agree. But I think that configurability makes the simulator more usable. Altough you can "build" a non-real CPU with a special configuration setting, you don't have to. It's up to Gabriele how he uses the software.
Besides that, I don't know how CPU inits MPR0-MPR6 registers, so I don't know how to simulate them.
According to https://kikb.web.fc2.com/PCE/mpr.html, MPR0-MPR6 are preserved across reset, and their power-on values are 0xff.
Thank you Phlipp, it's new to me. Implemented in [r16853].
Please note, that this breaks the regression testing completly.
The content of the hex file should be loaded directly to the chip object, using the new method: inspec and MPR setting can be done later by the crt0. Hex file should contain reset vector at the correct address, expected by MPR7=0.
Related
Commit: [r16853]
thanks!
the CRT setup the code start at 0x2200. ZP and stack should never be overwritten by code.
I'll modify the CRT to initialize the MPR registers.
How is the ihx file loaded?
is the address in the ihx the physical address regradless of the MP mapping?
BTW: I agree with Philipp. The simulator should be as close as the real HW as possible.
Last edit: Gabriele Gorla 2026-09-08
Daniel,
I am sorry but I need to reopen this one.
Either I completely don't understand how the mapping works in the simulator or there is something wrong.
referring to the simple attached example:
hex file starts at 0x2200. Reset/irq vectors at 0xfffa to 0xffff.
dump seems to read from mapped memory as trying
dump /x 0x1ffff8 0x1fffffhas no effect.Given the power on MPR values I should not see the reset vector at 0x1ffc and I should not see the startup code at 0x223f.
it seems the code is loaded at 0x1fe200 instead of 0x2200.
these are the first bytes of the startup code at 0x223f.
the reset vectors are also loaded incorrectly
The mapping seems reversed. the reset vector should be at physical 0x00fffa and logical 0x1ffa.
I finally got it.
adding
@rom_chipmakes the sim load the file correctly.However, I can't find any way to add this to the regression suite.
fixed in [r16875]
Related
Commit: [r16875]