Menu

#938 SuperCPU Executable Code in Bank $01

v3.1
open-need-info
nobody
None
xscpu64
2021-10-25
2017-09-25
Satpro
No

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

Discussion

  • Satpro

    Satpro - 2017-09-25

    I meant "Program Bank", not Program Counter. Apologies.

     
  • gpz

    gpz - 2017-09-25

    can you provide a small program that demonstrates this problem?

     
  • Satpro

    Satpro - 2017-09-25

    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.

     
  • gpz

    gpz - 2017-09-25

    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
  • Satpro

    Satpro - 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.

     
  • gpz

    gpz - 2017-10-04

    so DID you test it on the real thing?

     
  • Satpro

    Satpro - 2017-10-04

    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
  • gpz

    gpz - 2021-10-25

    closing this... no way to reproduce and not even tested on the real hardware, so who knows if its even a bug

     
  • Satpro

    Satpro - 2021-10-25

    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.

     
  • gpz

    gpz - 2021-10-25

    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.

     

Log in to post a comment.

MongoDB Logo MongoDB