search

lgblgblgb / xemu

Emulations (running on Linux/Unix/Windows/macOS, utilizing SDL2) of some - mainly - 8 bit machines, including the Commodore LCD, Commodore 65, and the MEGA65 as well.
https://github.com/lgblgblgb/xemu/wiki
GNU General Public License v2.0
207 stars 32 forks source link

MEGA65: adopt more decent hyppo #140

Closed lgblgblgb closed 2 years ago

lgblgblgb commented 4 years ago

Project status:

Highest priority for now

~So there should be some SD-controller emulation problem, that hickup thinks now, it's not an SDHC card. Though Xemu only emulates SDHC card. As hyppo seems to detect SDHC by trying non-sector aligned access (as with non-SDHC cards the addressing is byte based, but must be sector aligned, thus a method to detect it), but it should work anyway. So I assume, there is some generic problem with SD-controller emulation that a regular SD-sector read command fail, when it shouldn't.~

Jimbo on MEGA65/Xemu discord suggested a two line hack for keeping status read busy when external bus is selected for SD operation. This seems did the trick, however the whole SD-controller emulation is very messy ...

TODO list:

lgblgblgb commented 4 years ago

https://github.com/MEGA65/open-roms/issues/54

Reason why I may want to delay adopting a new Hyppo at least this 'early'.

lgblgblgb commented 2 years ago

A more fresh experiment, still the BRK problem:

CPU: at $AADB opcode = $A9 LDA #$nn A=FF X=00 Y=00 Z=3F SP=FD
CPU: at $AADD opcode = $8D STA $nnnn A=AA X=00 Y=00 Z=3F SP=FD
CPU: at $AAE0 opcode = $A9 LDA #$nn A=AA X=00 Y=00 Z=3F SP=FD
CPU: at $AAE2 opcode = $8D STA $nnnn A=0F X=00 Y=00 Z=3F SP=FD
CPU: at $AAE5 opcode = $A9 LDA #$nn A=0F X=00 Y=00 Z=3F SP=FD
CPU: at $AAE7 opcode = $8D STA $nnnn A=FF X=00 Y=00 Z=3F SP=FD
CPU: at $AAEA opcode = $A9 LDA #$nn A=FF X=00 Y=00 Z=3F SP=FD
CPU: at $AAEC opcode = $8D STA $nnnn A=F0 X=00 Y=00 Z=3F SP=FD
CPU: at $AAEF opcode = $60 RTS  A=F0 X=00 Y=00 Z=3F SP=FD
CPU: SP before RTS is (SPHI=$0100) SP=$FD
CPU: at $AFC0 opcode = $4C JMP $nnnn A=F0 X=00 Y=00 Z=3F SP=FF
CPU: at $080D opcode = $00 BRK  A=F0 X=00 Y=00 Z=3F SP=FF
CPU: WARN: BRK is about executing at PC=$080D

After this on the screen (no cursor, or ability to type):

xemu

Also before this:

execution outside of the hypervisor memory, PC = $5796

and (many similar):

WARNING: Unhandled memory write operation for linear address $FF10005 data = $D7 (PC=$761E)
CPU: at $761E opcode = $8E STX $nnnn A=D7 X=81 Y=FF Z=3F SP=F5
WARNING: Unhandled memory write operation for linear address $FF10006 data = $81 (PC=$7621)
CPU: at $7621 opcode = $8C STY $nnnn A=D7 X=81 Y=FF Z=3F SP=F5
WARNING: Unhandled memory write operation for linear address $FF10007 data = $FF (PC=$7624)
CPU: at $7624 opcode = $9C STZ $nnnn A=D7 X=81 Y=FF Z=3F SP=F5
WARNING: Unhandled memory write operation for linear address $FF10008 data = $3F (PC=$7627)
CPU: at $7627 opcode = $A2 LDX #$nn A=D7 X=81 Y=FF Z=3F SP=F5
CPU: at $7629 opcode = $BD LDA $nnnn,X A=D7 X=04 Y=FF Z=3F SP=F5
CPU: at $762C opcode = $9D STA $nnnn,X A=53 X=04 Y=FF Z=3F SP=F5
WARNING: Unhandled memory write operation for linear address $FF10004 data = $53 (PC=$762F)
CPU: at $762F opcode = $CA DEX  A=53 X=04 Y=FF Z=3F SP=F5
CPU: at $7630 opcode = $10 BPL $rr A=53 X=03 Y=FF Z=3F SP=F5
CPU: at $7629 opcode = $BD LDA $nnnn,X A=53 X=03 Y=FF Z=3F SP=F5
CPU: at $762C opcode = $9D STA $nnnn,X A=4F X=03 Y=FF Z=3F SP=F5
WARNING: Unhandled memory write operation for linear address $FF10003 data = $4F (PC=$762F)
lgblgblgb commented 2 years ago

Ok, what I've learnt today from Paul:

On Discord: https://discord.com/channels/719326990221574164/781481205639020554/917518905285685368

there are bunch of memory regions must be pre-filled with the right content (filled with the bitstream on MEGA65), only open-rom is not enough. The reason of the BRK, that hyppo tries to execute the flash menu, but it was not loaded, so only zero bytes there, thus the BRK problem occurs. Also, the check of hypervisor running outside of hypervisor RAM is largely outdated, as for now hickup does this by will, though maybe only the "boot" process, and after the first return from the first hypervisor call. it's still valid to have the check.

I may open a new branch to play with newer hyppo, as it seems it requires "some" re-work here and there, it won't be as easy to replace the hyppo image only. The new branch for the experiment: hyppo

Important "map file" for hyppo for debugging: src/hyppo/HICKUP.rep

Recommended mega65-core branch to get files from: master or hwsc (more bleeding edge)

Needed pre-initialized memory areas (according to Makefile):

$(TOOLDIR)/mempacker/mempacker_new -n shadowram -s 393215 -f $(VHDLSRCDIR)/shadowram-a100t.vhdl \
    $(SDCARD_DIR)/BANNER.M65@57D00 \
    $(SDCARD_DIR)/FREEZER.M65@12000 \
    $(SRCDIR)/open-roms/bin/mega65.rom@20000 \
    $(SDCARD_DIR)/ONBOARD.M65@40000 \
    $(UTILDIR)/megaflash-a100t.prg@50000

That it seems:

File address Comment
FREEZER.M65 $12000
open-rom $20000 used for boot process, will be overwritten by Hyppo from SD-card file MEGA65.ROM
ONBOARD.M65 $40000 boarding utility, ie setting initial parameters by user once, and store on SD card
megaflash-a100t.prg $50000 Flash-menu: not used in xemu (pointless), but a fake, xemu specific stub only
BANNER.M65 $57D00 the MEGA65 logo

NOTE: other files should be put on the emulated sd-card as well, as those may be loaded (once working freezer is a reality in Xemu) like sprite editor and things like that. TODO: get full list of needed files, let it be either memory-initialization purposes, or other.

lgblgblgb commented 2 years ago

Initial work committed to branch hyppo using brand new hickup (and other "system files") from the bleeding edge hwsc branch of mega65-core.

First, there is QSPI-flash issues, which is expected (this must be handled somehow, as the error is not fatal, but it's really annoying that emulator users always must to press the famous ANY key to continue, though doing so really allow to continue without any noticeable ill-effect):

xemu1

Second, there is an SD-card detection problem though:

xemu2

STATUS

This part is moved TO THE TOP of this page, since it was already confusing enough ...

lgblgblgb commented 2 years ago

~Idea about QSPI: it seems hickup just does a JMP $80D or so, to jump to the flash utility. That one exit with JMP $CF7F otherwise (like when printing that error). So, in theory, by using some own "stub-QSPI-flash-util" which is only that JMP opcode to $CF7F would may do the trick, so I don't need custom hickup for Xemu but avoid to dealing with the flash utility as much as possible.~

DONE, a minimal built-in program to Xemu is added to function as a "fake" version of the flash utility.

lgblgblgb commented 2 years ago

ONBOARD.M65 does an FPGA reconfiguration trigger by writing $42 to $D6CF. I've just implemented this by a reset. Now it does not stuck after save settings. However I'm still unsure, if it's a good idea to leave this tool in an emulator, or not ... I may replace it with a "stub" like with the flashing utility. However it would mean, Xemu's solution to write some config out as its own must be updated, since there is such a code, but I guess it's not valid anymore, that's the reason ONBOARD kicks in.

lgblgblgb commented 2 years ago

Added memory pre-init for reset routine to allow to access utility menu from emulation menu. Now the menu is displayed, however configure utility cannot be entered, only a white screen is shown. This worked before with older hyppo. The same for format/fdisk and keyboard test utilities :( I also see some BRK stuff here, after enabling in-deep debugging in Xemu to see what's happening.

lgblgblgb commented 2 years ago

What I've found: the utility menus causes a BRK at some point. The freezer activated with the normal way, hangs inside the hyppo for some SD-card busy testing :-/

lgblgblgb commented 2 years ago

The last (till now ...) issue

This worked before with Xemu, using older hyppo. Thus I consider this a regression. This is the last major problem. Note, invoking the Freezer never worked, and not scope of this issue (that's maybe #81 ). That is, solving this problem is the key to move on.

The utility menu invocation may goes wrong somewhere here:

CPU: at $B02B opcode = $22 JSR ($nnnn) A=EE X=0F Y=00 Z=3F SP=FB
CPU: 65CE02 opcode: JSR (nnnn)
CPU: at $EEB9 opcode = $78 SEI  A=EE X=0F Y=00 Z=3F SP=F9
CPU: at $EEBA opcode = $D8 CLD  A=EE X=0F Y=00 Z=3F SP=F9
CPU: at $EEBB opcode = $A9 LDA #$nn A=EE X=0F Y=00 Z=3F SP=F9
CPU: at $EEBD opcode = $8D STA $nnnn A=00 X=0F Y=00 Z=3F SP=F9
CPU: at $EEC0 opcode = $20 JSR $nnnn A=00 X=0F Y=00 Z=3F SP=F9
CPU: at $EC49 opcode = $20 JSR $nnnn A=00 X=0F Y=00 Z=3F SP=F7
CPU: at $FDD8 opcode = $08 PHP  A=00 X=0F Y=00 Z=3F SP=F5
CPU: at $FDD9 opcode = $48 PHA  A=00 X=0F Y=00 Z=3F SP=F4
CPU: at $FDDA opcode = $DA PHX  A=00 X=0F Y=00 Z=3F SP=F3
CPU: at $FDDB opcode = $5A PHY  A=00 X=0F Y=00 Z=3F SP=F2
CPU: at $FDDC opcode = $DB PHZ  A=00 X=0F Y=00 Z=3F SP=F1
CPU: 65CE02 opcode: PHZ
CPU: at $FDDD opcode = $A9 LDA #$nn A=00 X=0F Y=00 Z=3F SP=F0
CPU: at $FDDF opcode = $AA TAX  A=00 X=0F Y=00 Z=3F SP=F0
CPU: at $FDE0 opcode = $A8 TAY  A=00 X=00 Y=00 Z=3F SP=F0
CPU: at $FDE1 opcode = $4B TAZ  A=00 X=00 Y=00 Z=3F SP=F0
CPU: 65CE02 opcode: TAZ
CPU: at $FDE2 opcode = $5C MAP  A=00 X=00 Y=00 Z=00 SP=F0
CPU: 65CE02 opcode: MAP
CPU: MAP opcode, input A=$00 X=$00 Y=$00 Z=$00
MEM: applying new memory configuration because of MAP CPU opcode
LOW -OFFSET = $000, MB = $00
HIGH-OFFSET = $000, MB = $FF
MASK        = $00
MEM: memory_set_do_map() applied
CPU: at $FDE3 opcode = $EA EOM  A=00 X=00 Y=00 Z=00 SP=F0
CPU: 65CE02 opcode: EOM
CPU: EOM, interrupts were disabled because of MAP till the EOM
CPU: 65CE02 opcode: NOP
CPU: at $FDE4 opcode = $FB PLZ  A=00 X=00 Y=00 Z=00 SP=F0
CPU: 65CE02 opcode: PLZ
CPU: at $FDE5 opcode = $7A PLY  A=00 X=00 Y=00 Z=6B SP=F1
CPU: at $FDE6 opcode = $FA PLX  A=00 X=00 Y=20 Z=6B SP=F2
CPU: at $FDE7 opcode = $68 PLA  A=00 X=61 Y=20 Z=6B SP=F3
CPU: at $FDE8 opcode = $28 PLP  A=B0 X=61 Y=20 Z=6B SP=F4
CPU: at $FDE9 opcode = $60 RTS  A=B0 X=61 Y=20 Z=6B SP=F5
CPU: SP before RTS is (SPHI=$BE00) SP=$F5
CPU: at $8529 opcode = $00 BRK  A=B0 X=61 Y=20 Z=6B SP=F7
CPU: WARN: BRK is about executing at PC=$8529
CPU: BRK opcode linear address is $8529

This part: CPU: at $B02B opcode = $22 JSR ($nnnn) A=EE X=0F Y=00 Z=3F SP=FB seems to be this, in hyppo's code:

  2772  b029 f003                       beq @notOpenROM
  2773                                  ;; OpenROMs setup (XXX Won't work with Commodore C65 ROMs!)
  2774  b02b 22f8ff                     jsr ($fff8)
  2775                          @notOpenROM:

which is in main.asm, in hyppo's source, in subroutine setup_for_openrom:

setup_for_openrom:

        ;; Bank in KERNAL ROM space so megaflash can run
        ;; Writing to $01 when ZP is relocated is a bit tricky, as
        ;; we have to mess about with the Base Register, or force
        ;; the assembler to do an absolute write.
        lda #$37
        !8 $8d,$01,$00 ;; ABS STA $0001

        ;; We should also reset video mode to normal
        lda #$97
        trb $d054

        ;; Clear memory map at $4000-5FFF
        ;; (Why on earth do we even map some of the HyperRAM there, anyway???)
        lda #0
        tax
        tay
        ldz #$3f
        map
        eom
        ;; And set MB low to $00, so that OpenROM doesn't jump into lala land
        lda #0
        ldx #$0f
        map
        eom     

        ;; Tell KERNAL screen is at $0400
        lda #>$0400
        sta $0288

        lda $fff9
        cmp #$ff
        beq @notOpenROM
        ;; OpenROMs setup (XXX Won't work with Commodore C65 ROMs!)
        jsr ($fff8)

Interestingly, the very same routine runs during "normal boot" process as well, without any problems, like "meeting" BRK ...

lgblgblgb commented 2 years ago

hypervisor.c has been modified to support acme's sym file instead of Ophis based old solution. Still, there should be some interest for the "rep" file, as it would be able to provide a more detailed debug. Also, for real hyperdebug, probably the main loop should be modified for single step CPU emulation, otherwise this whole thing is kind of useless this way.

lgblgblgb commented 2 years ago

New finding: 1MHz mode does not work anymore :-O By git-bisecting all the commits in the hyppo branch (the last version in next is good, and that was forked to hyppo) it turned out the very first commit is to be blamed. But there is nothing in it, which can affect that :-O My conclusion that maybe the problem is older, as far as I remember, C128 "fast" (2MHz) mode bit was inverted. Even on MEGA65 (?) some time in the past. I am not sure now, what is the correct once, and why it was not a problem in next. Maybe newer hyppo sets something now correctly which was not done in the older, which worked "fine" with older Xemu cancelling the problem ;)

lgblgblgb commented 2 years ago

Now Xemu uses the "rep" acme file instead of "sym" for hyperdebug which contains informations like line number, source file, and the actual source lines as well (what now xemu all uses with hyperdebug). My main goal with this to ease my tries to debug emulation problems when hyppo is running, like the utility menu problem for example.

lgblgblgb commented 2 years ago

A possible solution (or at least a part of it, maybe) for the utility accessing problem of mine can be caused by a hyppo problem, see: https://github.com/MEGA65/mega65-core/issues/498

lgblgblgb commented 2 years ago

It really seems that CPU speed control has something to do with hyppo writing the C128 speed ctrl register on power-on by accident: https://github.com/MEGA65/mega65-core/issues/513 So it's even possible that I did a mistake to "fix" speed control in commit 33aa1b7a70b5a4eafcb9ed7c2871ca64b8b1b230 as hyppo accidentally set that C128 bit, thus I should not fix that with inverting the meaning of that bit (which only workaround'ed hyppo's move but making speed control inverted for any other software later then trying to use it!), since it would affect any program try to use that bit! :-O

lgblgblgb commented 2 years ago

Branch hyppo is now merged into next (the previous next into master). Though it's not perfect, it's finally mature enough to be at least "usage material" for wider audience keeping mind, that it can still buggy.

lgblgblgb commented 2 years ago

I close this issue now, since the main goal is achieved to have a usable emulation running a decent enough hyppo, and already has been a very bumpy and long road. Individual remaining and known bugs (and possible unknowns ...) should be addressed as-is after this.