LST file?

[lgblgblgb]

Testing with Xemu, it would be really handy to have an LST file for OpenROMs, ie, mostly the original source, but prefixed with actual PC addresses (and maybe generated byte codes). So the usual .lst file with assemblers. Xemu can produce detailed output of current PC values, but hard to figure out what it does and compare with the source. I'm not sure how hard to do it, ie KickAss can produce it, etc etc.

[FeralChild64]

I am going to drop the KickAssembler and move to ACME - in fact, this is the task I'm going to take now.

Is there any documentation regarding this .LST file format anywhere, or some examples? Currently the build system provides symbols to VICE (if you type, for example, make test), but the symbol files are not being published.

[lgblgblgb]

Oh, not so much a fixed format, anything would be superb which is more-or-less some LST file syntax. Typical assembler thing only, nothing fancy. I have no tool right now that I need any strict format, honestly for starter thing I would just like use that "manually" to compare Xemu PC values with the source part it belongs (I'm trying to adopt newer HICKUP for Xemu/MEGA65 emulator target which turned out needs OpenROM (according to Paul, I even haven't had the idea this is the case) but I encounter a BRK all the time after an RTS. I cannot say it's Xemu bug somewhere or what it is, unless I can debug it with some help for example an LST file). However surely, having such a file would be useful for many other things as well. But I may try the vice symbol file till that, it may be enough to locate the code fragment I'm interested in.

Btw, just found: http://forum.6502.org/viewtopic.php?f=2&t=5809

[lgblgblgb]

By the way, thanks for the vice sym file hint. However I can't find it for mega65.rom what I would need for, about the topic I mentioned above (yes, I'm aware that it's useless for vice as it won't emulate MEGA65, but I would use with Xemu/MEGA65 then ...).

[FeralChild64]

You will have to build the ROM by yourself - just type 'make all' or make 'test_mega65'. Go to build/target_mega65. The symbols are:

BASIC_0_combined.sym / BASIC_0_combined.vs - standard BASIC segment, $A000-$BFFF BASIC_1_combined.sym / BASIC_1_combined.vs - extended BASIC segment, gets banked in $4000-$7FFF KERNAL_0_combined.sym / KERNAL_0_combined.vs - standard KERNAL segment, $E000-$FFFF KERNAL_1_combined.sym / KERNAL_1_combined.vs - extended KERNAL segment, gets banked in $4000-$5FFF DOS_1_combined.sym / DOS_1_combined.vs - dummy DOS segment, gets banked in $4000-$7FFF

Before submitting symbols to VICE I always strip them from the ones containing double underscore - as they are duplicates/aliases of other (primary) symbols.

Once I finish with ACME migration, we can think about some debug data format (we need to take care about C65 banking scheme), depending what ACME can provide.

[lgblgblgb]

Thanks! I think I found what goes wrong with OpenROM in Xemu, an RTS returns to invalid address, I mean some garbage/data which is not even valid code, even has a 0 byte, thus causing a BRK. It seems the rts at the end of file screen_calculate_pntr_lnmx.s Though I'm still unsure there is no Xemu bug before/etc triggers that during new hyppo+pre-loaded openrom combo in Xemu.

[FeralChild64]

Strange, this routine does not have much potential to damage the stack, it probably happened earlier.

BTW. Are you sure you need the MEGA65 build for your purposes? It's not designed to be run in limited environment and can be really nasty sometimes - it maps/unmaps ROM to $4000-$5FFF or $4000-$7FFF and RAM to $8000-$BFFF, it manipulates VIC-IV settings, it starts in 80x50 text mode (and takes over some RAM above $000FFFF) if no cartridge is present, etc. Paul already had problems with it (when the ROM was far less advanced), and it will only get worse in the future.

Maybe try the generic build instead?

[lgblgblgb]

Honestly, I have no idea, I don't follow closely the hyppo development unfortunately since a while ... I just started to load the new hyppo and total failure, and then Paul told me, I also need to pre-load openrom to be able to work. Hopefully (I am not so sure anymore ...) I even tried that openrom built he gave me, so hopefully it's the right one. If I remember correctly I discovered that new hyppo did an JSR $FD15 for some reason I could not even understand (as Xemu's hypervisor execution check triggers fatal error if execution is outside of the hypervisor memory in hypervisor mode), that was the point when Paul reminded me that's because the need of pre-load of openrom. Btw, I cloned mega65-core which has sub-module open-rom, and I used that to have my own build too what I've tried as well besides of Paul's sent one. As you can see I'm a bit lame currently to try to catch up with more decent hyppo, and how I can put it into Xemu/MEGA65 to be able to work. Since sooner or later I need to upgrade hyppo, some software (like MODPLAY.prg I would also need to test the audio DMA emulation of Xemu/MEGA65) depends on newer hyppo already what Xemu can use without issue ... So to be clear, I don't want to use at this point openrom "normally" just I need it for the new hyppo to be able to work. That screenshot can be seen on "power-on" situation after about 19000 executed opcodes.

And yes, you're maybe right that the problem happens before just that RTS at the end of the routine triggers the problem, ie corrupted stack or whatever, so it returns to an address it should not ...

[gardners]

So the problem is that at the early boot time on the MEGA65, we have only the built-in pre-loaded ROM available, and yet, this still needs to be able to provide a proper MEGA65 BASIC if that is how the machine is configured (ie no SD card or no ROM on the SD card). It might be that we need to have a special vector in the openrom that does the necessary setup, or the openrom setup routines check if they are in hypervisor mode or not, and if so, tidy things back up again after.

[lgblgblgb]

OK, thanks to both of you. I guess I will pause my attempts to use newer Hyppo in Xemu till these things sorted out a bit, since I have hard time to decide that certain problem is Xemu's bug, or lack of emulation something, or not so much Xemu related thing at all (or in extreme cases, both at the same time to some degree ...).