SuperCPU Executable Code in Bank $01
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
While in Bank $01 (full Native mode with Kernal & BASIC ROMs switched out -- just straight RAM and I/O), executable code will not jump (jsr and jmp) properly from addresses $0000-$00ff. The program counter switches back to $00 and PC winds up at a non-sensical address. Move the "jump" code to $0100 and all is well. Many other instructions seem to work just fine, although I have not tested all 256. So far, it has only been with absolute jumps.
Thank you,
Bert
I meant "Program Bank", not Program Counter. Apologies.
can you provide a small program that demonstrates this problem?
Probably not. It is part of an OS we are working on, and it involves a new $F8 ROM and an entirely new way of using the VICE SuperCPU. The problem showed up when the RAM code was moved to $01:0000 from $01:0100. We were just trying to take advantage of an extra page. I have traced the execution countless times, eliminated other "stuff" as much as possible, and have had no luck whatsover. I wish I knew the answer. This only shows up when the code executes in the $00xx page of memory, and only (so far) for local, absolute jsr/jmp calls. Just thought I would ask here. The code can live just fine at $01:0100. Something is preventing address (and bank) resolution in jumps from $01:00xx while in Native mode with ROMs out.
are you sure it works on an actual scpu then?
in any case, without a testcase its pretty impossible to fix (or to confirm for that matter)
Last edit: gpz 2017-09-25
Well, that's fine. We will trudge on nonetheless. If and when I find the actual answer, it will be posted here.
so DID you test it on the real thing?
I have no idea how to burn a custom ROM for a real SuperCPU, and with the low number of units out there, it seems pointless. This is for a custom $F8 ROM which is downloaded to static RAM in much the same way as the original. We're trying something new -- a Native mode OS for VICE. Our fix was to move the code to $0100. It works great there, and those involved are fine with that. I consider it solved insofar as we have a workaround.
Last edit: Satpro 2017-10-04
closing this... no way to reproduce and not even tested on the real hardware, so who knows if its even a bug
I knew it was a real, re-producible bug a long time ago! More like... four years later, no one EVER bothered to look at it at all, and now it's time to clear out old un-solveds. S.O.P.
We are long past this one and know better than to write to Bank $01 < $0100. Good thing no one was holding their breath.
Not sure how you can be so confident without having checked a testcase on the real thing. Soci did a fairly good job with emulating a bunch of quirks, so perhaps that just is one of them. who knows. Since the problem apparently happens in RAM i dont see how you need to burn a ROM in order to test it either - unless there is more to it than what you reported.
However, since we dont even have a testcase, there is very little we can look at in order to fix it. None of the current team members has done any SCPU coding, so dont expect us to write that test program that we absolutely require to fix anything. Once we have that, we can have a look.