xemu xmega65

[Ben-401]

I couldnt find an existing thread on this, so thought id make one.

https://github.com/MEGA65/xemu
https://github.com/lgblgblgb/xemu

I refer to the emulator above.

I tried this out, and Yes, it works!

[Ben-401]

to install it, I had to do:

git clone https://github.com/MEGA65/xemu.git
make failed due to not having the "sdl" lib of 2.0.4 or more

lib 1.2 and 2 were no good.
sudo apt-get install libsdl1.2-dev
sudo apt-get install libsdl2-dev
sdl-config --version
sdl2-config --version

downloaded source of sdl from "https://www.libsdl.org/download-2.0.php"
got 2.0.4.tar.gz

tar xvfz 2.0.4.tar.gz
./configure
make install

then xemu/make
worked!

then
make roms

then copy in my KICKUP and sdcard-image into the ROMs directory.

then to run:
./build/bin/xmega65.native

[LGB Gábor Lénárt]

:) Actually, it's better to use my repository directly (the lgblgblgb one, who should be me, just lgb/lgblgb was not accepted by github hiiiiii). It's more up-to-date. That can be useful maybe as well:

https://github.com/lgblgblgb/xemu/wiki

Now, I am about to reconstructing the F011 emulation, first in the C65 emulator, in the hope that we have write support at last, which would be useful then both of the M65 emu of mine within Xemu project, and the "real" M65 as well.

[LGB Gábor Lénárt]

One more thing, that newer version (maybe not at MEGA65) supports an "internal" kickstart as well, if it can't found one, also no need for the C65 ROMs anymore and kickstart's task to load it from the SD image file. The reason that I depended on the external ROM file, is the missing charset. Now the one from M65 VHDL's is included in the emulator itself. So in theory - though I haven't tested very well, this is still a very pre-pre-pre-alpha version - only the SD image file is absolutely needed, the very same should be enough what a real M65 can use as well.

[Ben-401]

Hi Gabor,
when I make changes to the kickstart.a65 file (in the mega65-core project), then MAKE the KICKUP.file, normally I need to
- insert sdcard to pc, copy new KICKUP to sdcard, eject card,
- put card into nexys board, press reset, wait for the bin-file to load into fpga,
- then watch the serial-comms as KICKUP runs.
- and determine if the new KICKUP file performs what it was meant to.

Your emulator makes that process SO-MUCH easier, because I just need to run a script that put the files in place, and execute your emulator.

BUT, the serial comms performed by the emulator is really slow.
=> Can this be sped up?
Are you emulating the delay that the assembly in KICKUP performs?
The KICKUP assembly makes a call to the "Checkpoint" routine which writes char-by-char to the serial-port-component, and between each char sent, performs a tight-loop implementing a 2000-or-so clock cycle delay, which apparently gives the char enough time to be sent.

Maybe for me to improve the emulators serial-port Checkpoint-messages, I should remove this 2000-or-so clock-cycle-delay.

Your thoughts?

[Paul Gardner-Stephen]

Yes, skipping the 2000 cycle delay would speed it up.  We should implement a ready flag for the serial write interface, as we discussed in the lab.  That way the same code can be used on the emulator and real hardware, without the emulation being slower than necessary.

Paul.

--
You received this message because you are subscribed to the Google Groups "C65GS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[LGB Gábor Lénárt]

Hi Ben,

On Saturday, September 10, 2016 at 10:06:11 AM UTC+2, Ben-401 wrote:

Hi Gabor,
when I make changes to the kickstart.a65 file (in the mega65-core project), then MAKE the KICKUP.file, normally I need to
- insert sdcard to pc, copy new KICKUP to sdcard, eject card,
- put card into nexys board, press reset, wait for the bin-file to load into fpga,
- then watch the serial-comms as KICKUP runs.
- and determine if the new KICKUP file performs what it was meant to.

Your emulator makes that process SO-MUCH easier, because I just need to run a script that put the files in place, and execute your emulator.

BUT, the serial comms performed by the emulator is really slow.
=> Can this be sped up?
Are you emulating the delay that the assembly in KICKUP performs?
The KICKUP assembly makes a call to the "Checkpoint" routine which writes char-by-char to the serial-port-component, and between each char sent, performs a tight-loop implementing a 2000-or-so clock cycle delay, which apparently gives the char enough time to be sent.

Yes, I guess the "problem" here that kickstart itself waits a lot here. Also please note that Xemu/mega65 currently still emulates the C65's ~3.5MHz speed, no 48MHz mode, etc. So in fact, this can be kinda slow, especially if kickstart even waits thinking the delay time of 48MHz CPU, that would be more than 10 times slower then on my current emulator :-( I think, you should comment out the waiting in kickstart source to speed things up :) This is not a real hardware, you don't need to wait to transfer CP messages over a serial link or so, it can be done "at full speed" too, and will work. As you have noted to :)

One more thing: if you place kickstart.list file into the directory where SD image, and KICKUP.M65 needs to be placed as well, Xemu will use that to check code execution. What means, that in hypervisor mode, if PC gets to a position out-of-bound-of-code, it will panic. Paul asked that, to be useful with checking not ending up to execute at bad PC (ie jumping "inside" an opcode, I mean). However please careful, if you have the list file and KICKUP.M65 as well and you forget to update one, it will cause problems that Xemu will have false information, since the list file and kikcup not really about the same version exactly :D

Meanwhile, about Paul's comment: indeed, it should be quite nice to have a serial ready flag. Another solution is to provide a way to query if it's real HW or emulator. It can be used at many places then in the future as well. However it has a negative effect: in case of an emulator I would expect to be a *GOOD* emulation. If code depends heavily to have two different path of execution on emu and the real thing, it's not so nice always ... Maybe the ready flag is a much better idea!!!

About the SD-card copy issue: isn't it possible to "get" the new kickup via ethernet so you no need to swap/copy/etc SD-card of the board again and again? :)

[Ben-401]

Hi Gabor,
Yes I got your repo directly.
I have removed the 2000 delay and it is almost instantaneous fast.
I run into a problem with loading data from the sdcard.image
Hypervisor serial output: "CP@$8C5F AXYZP=30,30,30,00,34 :dos_readdir[0000]==========================================  ".
Hypervisor serial output: "CP@$9D4F AXYZP=30,30,30,00,34 :sd_sector: $d681=00000000.                                   ".
Hypervisor serial output: "CP@$9E04 AXYZP=30,30,30,00,34 :FD<=00,80,00,00,00,00,00,00                                  ".
Hypervisor serial output: "CP@$9E84 AXYZP=30,30,30,00,34 :FD>=00,00,00,00,00,00,00,00                                  ".
Hypervisor serial output: "CP@$9F18 AXYZP=00,00,00,00,36 :SDcard mode, ie not SDHC, so shifting                        ".
Hypervisor serial output: "CP@$9D4F AXYZP=30,30,30,00,34 :sd_sector: $d681=FFFFFC00.                                   ".
ERROR: SDCARD: invalid position value failure!! 4294966272 (limit = 67108864)
XEMU: shutdown callback says good by(T)e to you!

the above is the first time I have seen the "$d681=FFFFFC00" (just prior to crash).
I will need to review my kickup.code to see if i have made a boo-boo.

Secondly, i find it difficult to copy my modified KICKUP.M65 into the "mega65.img".
it seems in the "./rom/Makefile" does not depend on KICKUP.M65 for the "mega65.img" target.

Yes I like the serial-ready/busy-flag idea, and will try implement.

No, I cannot seem to get the ethernet working effectively.

[LGB Gábor Lénárt]

Hi Ben,

First, you need to forget rom/Makefile, it's not so much ready for this, it is unfinished!!! I should even remove those stuffs not to confuse people ... It was my try to have an image file builder, but the one (your script, if I remember correctly in mega65-core repo) works at least :-P Anyway: You don't need to copy KICKUP.M65 to sdcard image though (mega65.img). Xemy/M65 simply loads KICKUP.M65 from the host file system directly. Then when kickstart asks if it's OK to upgrade, you simply select the "already upgraded stuff" so kickstart is "faked' that it's already upgraded. In this way, you can use the KICKUP.M65 file _outside_ of the SD-card image file. This was my original plan, to make it easy to test kickstart, ie no need to copy it onto the card image file. Now emulator even has a kickstart embedded into it, so in theory it is able to work (after time dialog box questions) without any KICKUP.M65 file, then you can proceed to use that with the trick above, or you can allow the kickstart already upgraded hypervisor register to set 'not upgraded' thus KS will do then and upgrade itself from the card. I wanted to provide a way to test "external" KICKUP (ie, from host OS fs) loaded for easier test, but also to allow to use from SD-card, moreover, the embedded kickstart into the emulator allows to "fallback" on that, if there is nothing M65 emulator can start with (I guess on realy M65 the situation is handled as KS is part of the bitstream, which can upgrade itself from the card). Ok, too much blah-blah from me, hopefully I could express well enough what I had on my mind here :)

My longer term plan to help emulator users, with the disk image self-creation/manipulation built-in feature in the emulator. What I mean here, if you develop a program for M65 and want to test with the emulator, it's a bit uncomfortable to always copy that onto the image file, and use the emulator then ... So Xemu - I think - should have the ability to accept at least single files, D81 images, and SD-card image. The last one would be used as-is, no problem, like a real M65. D81 image file given to the emulator would cause Xemu to build an SD-card image internally, instantly, on-the fly, and use that with D81 copied on that, so user can test its program easily. Maybe even file (or files) can be given, in that case, those will be copied onto a D81 image which is again copied on the SD-card image, all of these operations are purely transparent and instant for the user, much more an internal issue of the emulator than a user noticeable stuff. I even think about D64->D81 on-the fly conversion, if D64 is given (ok, maybe that would cause not to work then, if there is something really bound to the disk format, but in general even cbmconvert can convert D64 to D81). These wouldn't be scripts, etc, but part of the emulator coded in C, though that's a bit hard problem to support than at least D64/D81 internals, Fat32 internals, and so, you see. But I really would like to give the possibility for easy use, with keeping also the possibility to use SD-card images (or even real SD-cards, it's possible now too, at least in case of Linux, if you symlink the /dev/ node of the card to mega65.img, and you have rights to access the device for your user ...).

Serial busy idea is indeed nice. VHDL implementation can really provide a counter/etc to change into not-busy state after the desired time on that register, while in Xemu, I would "fake" the non-busy state all the time, since I need no (emulated) time to flush a character :) Also, what Xemu starts to lack if the any of the user control. I mean, there is F9 to exit, F10 to reset (may not work well with M65?) and F12 to toggle window/fullscreen mode, but that's all. Soon, there should be some more controls run-time, ie FPGA switches can be altered on the run (even switch-12 ...) and of course more ideas will come .... I wouldn't like to use "real GUI" since it's OS dependent, and then there should be GUI for Windows, Linux, OSX ...

[LGB Gábor Lénárt]

By the way, this invalid sector read can be (however guessing only without the actual knowledge here too much), because KS does not know well the size of the directory in sectors? Sorry, I can't remember about FAT details now, if root directory is also FAT booked, ie with the "next pointers" so maybe KS will try to read the next cluster corresponding to the directory which was actually not belongs it already. I mean what if the end-of-chain sign is interpreted as cluster number by KS and converted into SD block, so that's the reason for strange offset it wants to read. Though, as I've told, I am not sure if root directory is also "FAT chained" .... AFAIK, I have the faint memory about the fact that FAT32 is different in this topic than FAT12/16, that is it uses FAT for the root directory as well, where it was a "fixed" area with FAT12/16. However I am not sure how it was ...

[LGB Gábor Lénárt]

Sorry for the lots of answers :) Just a new experience now, what I found with the emulator as well, that is: if I tried to create an SD card image (directly an image file _or_ doing it on a card, then dd'ing into an image file) it was always problematic for my M65 emulator + KS. Ok, that can be a bug in my emulator. However it worked with an image file, sent by Deft. Now I see the same issue with the real board as well. Deft's image on the card: everything works. Now I only wanted to change the ROM file (to test a newer ROM) so I mounted the card in Linux, and changed the ROM file on the card. After this, KS/M65 (now the board itself, not my emulator) didn't find anything, the partition is mounted, that was reported, but every files it tried to locate was "not found", including the ROM. It seems KS is picky for some reason of my Linux touches the card :-) What is odd for a reason: I often use my Linux box to copy files, etc from/onto FAT32 formatted cards also used by digital camera, etc, and haven't got any issue yet with this.

[Ben-401]

Hi Gabor,

I have tried your repo version of the xemu. I now have a problem and I dont know where to look to solve this. Can you please help by giving some direction on where the problem may be?
It compiles good using ubuntu, i just needed the SDL2 libraries. Here is what I did:

$ git clone https://github.com/lgblgblgb/xemu.git

$ make roms
<details omitted>

$ make roms
make -C rom
make[1]: Entering directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/rom'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/rom'

$ cd targets/mega65

targets/mega65$ make
<details omitted, see next post>

targets/mega65$ make
make do-all
make[1]: Entering directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'
make ../../build/objs/m-native-mega65-xmega65--make.depend
make[2]: Entering directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'
make[2]: '../../build/objs/m-native-mega65-xmega65--make.depend' is up to date.
make[2]: Leaving directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'
make ../../build/bin/xmega65.native
make[2]: Entering directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'
make[2]: '../../build/bin/xmega65.native' is up to date.
make[2]: Leaving directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'
make[1]: Leaving directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'

targets/mega65$ cd ./../..

$ ./build/bin/xmega65.native
**** The Incomplete Commodore-65/Mega-65 emulator from LGB ****
CREATED: gerb0002@dell960 on Linux 4.2.0-42-generic at Mon Dec 19 11:53:48 ACDT 2016 with gcc 5.2.1 20151010 64LE for unix
VERSION: https://github.com/lgblgblgb/xemu.git master b9df2f3139d2f621c30d11f69e432460c0264a7e
EMULATE: MEGA65 (mega65): xmega65 (../../build/bin/xmega65.native) for mega65 on native using gcc
LICENSE: Copyright (C)2016 Gábor Lénárt (aka LGB) lxxxxxu http://lgb.hu/
LICENSE: This software is a GNU/GPL version 2 (or later) software.
LICENSE: <http://gnu.org/licenses/gpl.html>
LICENSE: This is free software; you are free to change and redistribute it.
LICENSE: There is NO WARRANTY, to the extent permitted by law.

Logging into file: not enabled.
SDL version: (hg-10001:e12c38730512) compiled with 2.0.4, used with 2.0.4 on platform Linux
SDL system info: 64 bits LE, 2 cores, l1_line=64, RAM=5805Mbytes, CPU features: 3DNow=0 AVX=0 AVX2=0 AltiVec=0 MMX=1 RDTSC=1 SSE=1 SSE2=1 SSE3=1 SSE41=1 SSE42=0
SDL drivers: video = x11, audio = pulseaudio
Timing: sleep = nanosleep, query = SDL_GetPerformanceCounter
SDL preferences directory: /home/gerb0002/.local/share/xemu-lgb/mega65/
SDL renderer driver #2: "software"
SDL renderer driver #1: "opengles2"
SDL renderer driver #0: "opengl"
SDL renderer used: "opengl" max_tex=8192x8192 tex_formats=5 (SDL_PIXELFORMAT_ARGB8888 SDL_PIXELFORMAT_YV12 SDL_PIXELFORMAT_IYUV SDL_PIXELFORMAT_NV12 SDL_PIXELFORMAT_NV21)

Trying to open file "KICKUP.M65" as "./KICKUP.M65" ...
Trying to open file "KICKUP.M65" as "./rom/KICKUP.M65" ...
Trying to open file "KICKUP.M65" as "/home/gerb0002/.local/share/xemu-lgb/mega65//KICKUP.M65" ...
Trying to open file "KICKUP.M65" as "/home/gerb0002/dev/lgblgblgb-xemu/xemu/build/bin//KICKUP.M65" ...
Trying to open file "KICKUP.M65" as "/usr/local/lib/xemu/KICKUP.M65" ...
Cannot open file KICKUP.M65
WARNING: Kickstart KICKUP.M65 cannot be found. Using the default (maybe outdated!) built-in version
Trying to open file "mega65.img" as "./mega65.img" ...
Trying to open file "mega65.img" as "./rom/mega65.img" ...
Trying to open file "mega65.img" as "/home/gerb0002/.local/share/xemu-lgb/mega65//mega65.img" ...
Trying to open file "mega65.img" as "/home/gerb0002/dev/lgblgblgb-xemu/xemu/build/bin//mega65.img" ...
Trying to open file "mega65.img" as "/usr/local/lib/xemu/mega65.img" ...
Cannot open file mega65.img
ERROR: Cannot open SD-card image mega65.img, SD-card access won't work! ERROR: No such file or directory
ERROR: Cannot find SD-card image (which is a must for Mega65 emulation): mega65.img

XEMU: shutdown callback says good by(T)e to you!

I then copied into the "./rom" dir the "KICKUP.M65" and "mega65.img" files I had on hand, and re-run the emulator:

$ ./build/bin/xmega65.native
**** The Incomplete Commodore-65/Mega-65 emulator from LGB ****
CREATED: gerb0002@dell960 on Linux 4.2.0-42-generic at Mon Dec 19 11:53:48 ACDT 2016 with gcc 5.2.1 20151010 64LE for unix
VERSION: https://github.com/lgblgblgb/xemu.git master b9df2f3139d2f621c30d11f69e432460c0264a7e
EMULATE: MEGA65 (mega65): xmega65 (../../build/bin/xmega65.native) for mega65 on native using gcc
LICENSE: Copyright (C)2016 Gábor Lénárt (aka LGB) lxxxxxxxu http://lgb.hu/
LICENSE: This software is a GNU/GPL version 2 (or later) software.
LICENSE: <http://gnu.org/licenses/gpl.html>
LICENSE: This is free software; you are free to change and redistribute it.
LICENSE: There is NO WARRANTY, to the extent permitted by law.

Logging into file: not enabled.
SDL version: (hg-10001:e12c38730512) compiled with 2.0.4, used with 2.0.4 on platform Linux
SDL system info: 64 bits LE, 2 cores, l1_line=64, RAM=5805Mbytes, CPU features: 3DNow=0 AVX=0 AVX2=0 AltiVec=0 MMX=1 RDTSC=1 SSE=1 SSE2=1 SSE3=1 SSE41=1 SSE42=0
SDL drivers: video = x11, audio = pulseaudio
Timing: sleep = nanosleep, query = SDL_GetPerformanceCounter
SDL preferences directory: /home/gerb0002/.local/share/xemu-lgb/mega65/
SDL renderer driver #2: "software"
SDL renderer driver #1: "opengles2"
SDL renderer driver #0: "opengl"
SDL renderer used: "opengl" max_tex=8192x8192 tex_formats=5 (SDL_PIXELFORMAT_ARGB8888 SDL_PIXELFORMAT_YV12 SDL_PIXELFORMAT_IYUV SDL_PIXELFORMAT_NV12 SDL_PIXELFORMAT_NV21)

Trying to open file "KICKUP.M65" as "./KICKUP.M65" ...
Trying to open file "KICKUP.M65" as "./rom/KICKUP.M65" ...
OK, file is open (fd = 10)
Trying to open file "mega65.img" as "./mega65.img" ...
Trying to open file "mega65.img" as "./rom/mega65.img" ...
OK, file is open (fd = 10)
HYPERVISOR: entering into hypervisor mode @ $FFFF -> $8100
ERROR: Unhandled memory read operation for linear address $FFFC000 (PC=$A0C6)

XEMU: shutdown callback says good by(T)e to you!

I then downloaded and used the "img" file from
https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/sd-card-image-for-xemu-xmega65.img.gz
with my previous KICKUP.M65 file, and re-run

$ ./build/bin/xmega65.native
**** The Incomplete Commodore-65/Mega-65 emulator from LGB ****
CREATED: gerb0002@dell960 on Linux 4.2.0-42-generic at Mon Dec 19 11:53:48 ACDT 2016 with gcc 5.2.1 20151010 64LE for unix
VERSION: https://github.com/lgblgblgb/xemu.git master b9df2f3139d2f621c30d11f69e432460c0264a7e
EMULATE: MEGA65 (mega65): xmega65 (../../build/bin/xmega65.native) for mega65 on native using gcc
LICENSE: Copyright (C)2016 Gábor Lénárt (aka LGB) xxxxxx http://lgb.hu/
LICENSE: This software is a GNU/GPL version 2 (or later) software.
LICENSE: <http://gnu.org/licenses/gpl.html>
LICENSE: This is free software; you are free to change and redistribute it.
LICENSE: There is NO WARRANTY, to the extent permitted by law.

Logging into file: not enabled.
SDL version: (hg-10001:e12c38730512) compiled with 2.0.4, used with 2.0.4 on platform Linux
SDL system info: 64 bits LE, 2 cores, l1_line=64, RAM=5805Mbytes, CPU features: 3DNow=0 AVX=0 AVX2=0 AltiVec=0 MMX=1 RDTSC=1 SSE=1 SSE2=1 SSE3=1 SSE41=1 SSE42=0
SDL drivers: video = x11, audio = pulseaudio
Timing: sleep = nanosleep, query = SDL_GetPerformanceCounter
SDL preferences directory: /home/gerb0002/.local/share/xemu-lgb/mega65/
SDL renderer driver #2: "software"
SDL renderer driver #1: "opengles2"
SDL renderer driver #0: "opengl"
SDL renderer used: "opengl" max_tex=8192x8192 tex_formats=5 (SDL_PIXELFORMAT_ARGB8888 SDL_PIXELFORMAT_YV12 SDL_PIXELFORMAT_IYUV SDL_PIXELFORMAT_NV12 SDL_PIXELFORMAT_NV21)

Trying to open file "KICKUP.M65" as "./KICKUP.M65" ...
Trying to open file "KICKUP.M65" as "./rom/KICKUP.M65" ...
OK, file is open (fd = 10)
Trying to open file "mega65.img" as "./mega65.img" ...
Trying to open file "mega65.img" as "./rom/mega65.img" ...
OK, file is open (fd = 10)
HYPERVISOR: entering into hypervisor mode @ $FFFF -> $8100
ERROR: Unhandled memory read operation for linear address $FFFC000 (PC=$A0C6)

XEMU: shutdown callback says good by(T)e to you!

The graphical window appears, black screen, with a dialog saying "ERROR: Unhandled memory read operation for linear address $FFFC000 (PC=$A0C6)".
I note the FD=10 for both KICKUP.M65 and mega65.img files.

Thanks,
Ben,.

[Ben-401]

Below is the compile of the mega65 target

targets/mega65$ make
make do-all
make[1]: Entering directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'
make ../../build/objs/m-native-mega65-xmega65--make.depend
make[2]: Entering directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'

gcc -MM -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h mega65.c vic3.c sdcard.c uart_monitor.c hypervisor.c m65_snapshot.c > ../../build/objs/m-native-mega65-xmega65--make-target-pre.depend
awk '/^[^.:\t ]+\.o:/ { print "../../build/objs/t-native-mega65-xmega65--" $0 ; next } { print }' < ../../build/objs/m-native-mega65-xmega65--make-target-pre.depend > ../../build/objs/m-native-mega65-xmega65--make-target.depend
gcc -MM -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h ../../xemu/emutools.c ../../xemu/cpu65c02.c ../../xemu/cia6526.c ../../xemu/emutools_hid.c ../../xemu/sid.c ../../xemu/f011_core.c ../../xemu/f018_core.c ../../xemu/c64_kbd_mapping.c ../../xemu/emutools_config.c ../../xemu/emutools_snapshot.c ../../xemu/emutools_buildinfo.c > ../../build/objs/m-native-mega65-xmega65--make-common-pre.depend
awk '/^[^.:\t ]+\.o:/ { print "../../build/objs/c-native-mega65-xmega65--" $0 ; next } { print }' < ../../build/objs/m-native-mega65-xmega65--make-common-pre.depend > ../../build/objs/m-native-mega65-xmega65--make-common.depend
cat ../../build/objs/m-native-mega65-xmega65--make-target.depend ../../build/objs/m-native-mega65-xmega65--make-common.depend > ../../build/objs/m-native-mega65-xmega65--make.depend
rm -f ../../build/objs/m-native-mega65-xmega65--make-target-pre.depend ../../build/objs/m-native-mega65-xmega65--make-common-pre.depend

make[2]: Leaving directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'
make ../../build/bin/xmega65.native
make[2]: Entering directory '/home/gerb0002/dev/lgblgblgb-xemu/xemu/targets/mega65'

gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/t-native-mega65-xmega65--mega65.o mega65.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/t-native-mega65-xmega65--vic3.o vic3.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/t-native-mega65-xmega65--sdcard.o sdcard.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/t-native-mega65-xmega65--uart_monitor.o uart_monitor.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/t-native-mega65-xmega65--hypervisor.o hypervisor.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/t-native-mega65-xmega65--m65_snapshot.o m65_snapshot.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--emutools.o ../../xemu/emutools.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--cpu65c02.o ../../xemu/cpu65c02.c
../../xemu/cpu65c02.c:97:2: warning: #warning "Compiling for MEGA65, hacky stuff!" [-Wcpp]
 #warning "Compiling for MEGA65, hacky stuff!"
  ^
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--cia6526.o ../../xemu/cia6526.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--emutools_hid.o ../../xemu/emutools_hid.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--sid.o ../../xemu/sid.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--f011_core.o ../../xemu/f011_core.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--f018_core.o ../../xemu/f018_core.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--c64_kbd_mapping.o ../../xemu/c64_kbd_mapping.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--emutools_config.o ../../xemu/emutools_config.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--emutools_snapshot.o ../../xemu/emutools_snapshot.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/c-native-mega65-xmega65--emutools_buildinfo.o ../../xemu/emutools_buildinfo.c
gcc -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -Wall -pipe -I/usr/local/include/SDL2 -D_REENTRANT -D HAVE_SDL2 -DDATADIR=\"/usr/local/lib/xemu\" -I. -I../.. -include xemu/arch-sys-native.h -c -o ../../build/objs/m-native-mega65-xmega65--make-buildinfo.o ../../build/objs/m-native-mega65-xmega65--make-buildinfo.c
gcc -o ../../build/bin/xmega65.native ../../build/objs/t-native-mega65-xmega65--mega65.o ../../build/objs/t-native-mega65-xmega65--vic3.o ../../build/objs/t-native-mega65-xmega65--sdcard.o ../../build/objs/t-native-mega65-xmega65--uart_monitor.o ../../build/objs/t-native-mega65-xmega65--hypervisor.o ../../build/objs/t-native-mega65-xmega65--m65_snapshot.o ../../build/objs/c-native-mega65-xmega65--emutools.o ../../build/objs/c-native-mega65-xmega65--cpu65c02.o ../../build/objs/c-native-mega65-xmega65--cia6526.o ../../build/objs/c-native-mega65-xmega65--emutools_hid.o ../../build/objs/c-native-mega65-xmega65--sid.o ../../build/objs/c-native-mega65-xmega65--f011_core.o ../../build/objs/c-native-mega65-xmega65--f018_core.o ../../build/objs/c-native-mega65-xmega65--c64_kbd_mapping.o ../../build/objs/c-native-mega65-xmega65--emutools_config.o ../../build/objs/c-native-mega65-xmega65--emutools_snapshot.o ../../build/objs/c-native-mega65-xmega65--emutools_buildinfo.o ../../build/objs/m-native-mega65-xmega65--make-buildinfo.o -Ofast -fno-common -falign-functions=16 -falign-loops=16 -ffast-math -L/usr/local/lib -Wl,-rpath,/usr/local/lib -lSDL2 -lm

[LGB Gábor Lénárt]

Hi Ben,

Sorry about the delay, Christmas etc, and two ill kids + wife :-/ Anyway. I think, there is some problem with the kickstart here. ERROR: Unhandled memory read operation for linear address $FFFC000 (PC=$A0C6)".
$FFFC000 is the byte _after_ the kickstart area, so the control should not pass there. Xemu has some "protection" which does not allow read (including execute) or write for a memory range it does not emulate. Are you sure it's the right kickstart (ie KICKUP.M65)? Anyway, you can try to delete it. In theory, it should work, since Xemu/Mega65 also contains a "built-in" kickstart, if it cannot find one to load. Also watch out from the output, what file Xemu loads, since it tries various places and maybe it won't found the file you mean, but some other one with the same name in another directory you may expect :) Honestly, this is kinda lame from me :) I have the a plan to have some "bulit-in installer" ie, if you start Xemu it offers download the needed files into the preferences directory only. The current situation that Xemu tries many places, is because I wanted it to be usable after compilation and started from there, and also in the case if you place the binary somewhere, etc etc. Clearly, it's not the ideal solution!

[Gurce Isikyildiz]

Hi Gabor,

I'm also trying to get familiar with using your xemu emulator for the mega65. I've tried to garner insights from this thread, but some aspects had me scratching my head a little, so I thought I'd better verify them with you:

I just wanted to clarify with you the purpose of these two options shown during startup. I've tried describing them as I've understood them so far and I think I'm probably slightly wrong to some extent, so would be happy to be correct:

• Xemu emulator begins running
• Default kickstart code runs
• On the Nexys hardware: this is a copy of kickstart that was built into the bitstream.
• In the xemu emulator: is this a copy that gets compiled into the final xemu executable/binary?
• Then there is the test for the existence of a KICKUP.M65 file (used as a way to easily upgrade kickstart)
• On the Nexys hardware: it searches for a KICKUP.M65 file on the sd-card. If found, it makes use of it
• In the Xemu emulator:
• it searches various paths on your system. On my macbook, it seemed to scan through these paths:
    - ./KICKUP.M65
    - ./rom/KICKUP.M65
    - ~/Library/Application Support/xemu-lgb/KICKUP.M65
    - ./build/bin/KICKUP.M65
    - /usr/local/lib/xemu/KICKUP.M65
• If it can't find one here, I think it makes use of a KICKUP.M65 that was compiled into the final executable/binary?
• Then the emulator provides the user an option of making use of this KICKUP.M65 or not
• "Already upgraded, I test kicked state"
  - This will load the KICKUP.M65 file (whether it was found in the scanned paths, or the default KICKUP.M65 compiled into the xemu executable/binary?)
• "Not upgraded yet, it can do it"
  - This option will let the present kickstart continuing running as-is, and not bother upgrading it to any KICKUP.M65 file (whether they exist or not).

How did I go? Is that about right?

Also, I'm a bit puzzled by the expression "..., it(1) can do it(2)", what are it(1) and it(2)? My guess was:

• Is it(1) the xemu emulator?
• Is it(2) the xemu emulator making use of its own kickstart, and not need any kickup?

Regards,

Gurce

[Gurce Isikyildiz]

Just as an aside, I thought I'd try see if xemu would build and run within WinXp+Cygwin, and would it then be able to talk to m65dbg in winxp too then?

Made some progress in that direction.

• One gotchya was that xemu requires SDL v2.0.4, whereas Cygwin only comes with SDL v2.0.3
  - I tried working around this by tweaking the code to remove and v2.0.4 specific elements
• The latest Cygwin no longer supports WinXP. You need to make use of "Cygwin Time Machine" if you're hell-bent on using WinXP+Cygwin now (which I did on this occasion).
• There were various Cygwin packages that needed to be installed:
  - libSDL2-devel
  - libSDL2_2.0_0
  - libgtk3-devel
  - libgtk3_0
  - xinit (to get your x-server)
  
• The x-server had some problems in multi-window mode, and I needed to run it manually from within a cygwin terminal, with the following parameters (to avoid problems with indirect GLX contexts, whatever they may be):
  
  startxwin -- -multiwindow +iglx -nowgl
   
• After doing so, I can finally run xemu and I get it running in WinXP, yippee! :)
  

But how about the unix-domain socket connection to m65dbg, does that work in WinXP+Cygwin?

Well, initially, the m65dbg app seemed to freeze after typing the first command, but I've updated the code to avoid this and now it seems to work fine, whew :)

Here's some visual confirmation :)

Regards,

Gurce

[Gurce Isikyildiz]

Oh, and just for reference, I'll attach a patch file of the tweaks I made to xemu to get it running in winxp+cygwin.

[Ben-401]

Well done Gurce,
I also made some progress.
Please see:
https://github.com/MEGA65/mega65-core/blob/development/doc/xemu.md
for install instructions on xemu.

I found that I didnt have to install GTK3 as that package was only needed for the 'ep128' target...
I am also on the way in using the xemu.
Ben.

[LGB Gábor Lénárt]

Hi Gurce,

This question box can be strange for simple people indeed. What it wants to be: kickstart during the "boot" process checks if it was already "upgraded" or not. As far as I can understand this is to avoid the "infinite looping" issue. What I mean here: the M65 board's BIT file contains some kind of "initial" kickstart, as the board needs some code to run, even before the SD card is initialized. However, after that, if KS founds the KICKUP.M65 file on the SD-card, it can "upgrade" itself. But after doing so, it will find that file again with the upgraded KS. So this can be a reason, M65 implements an "already upgraded" state, to avoid this. Now with the emulator: a real M65 wouldn't ask this, and KS always (?) upgrade itself. However I feel that it's better in the emulator to allow this being configurable. That's the meaning of this question. This can be set by command line options btw. Run the mega65 emulator executable with the -h switch, so you can get the list of command line options. You will notice the -kicked option, and some others. This is especially useful, if you want to use an external kickstart and you want to avoid to upgrade it from the SD card image.

Ok, about the questions then. Please note, that I can be wrong with the actual hardware version of M65 (that is, the nexys4 board):

The initial kickstart is built in the bitstream file. In xemu there are more sources. It tries to load it from the "preferences directory" of the emulator (just watch the output of the emulator, if you start from a terminal window or so, no idea about Windows, I more mean of UNIX-like OSes here, OSX or Linux) so you can see what kind of files Xemu tries to open and from where. You can also specify a kickstart with command like option -kickup however, Xemu itself contains a built-in KS as well, if these fails! That solution basically would be similar as with the board with some KS within the bitstream itself (however Xemu's embedded KS can be kinda old ...).

The second "group" of your questions are a bit confusing. Let's see from the point of view of the emulated hardware (the nexys4 board again, with the proper bitstream fof course), what xemu wants to emulate that. Xemu does about the same with KS. I mean, forget SD-card now, since we are before that state of "booting". So the real M65 (I use this term for the board+M65 bitstream configured FPGA) the "initial" KS is built in the the bitstream itself. For xemu it is:

* you can specify one with the -kickup command line option
* xemu tries to find KICKUP.M65 with testing various PATHs

Please note, that the second is OS-specific and compilation setting related. What you quoted "~/Library/Application Support/xemu-lgb/KICKUP.M65" is maybe the OSX default path for the so called SDL "preferences directory" but there it can be changed in the future by SDL2 itself too and it's SURELY differnt on Windows, Linux etc. The idea here, that SDL2 tries to give you a read/writable OS-independent directory for *all* platforms SDL2 supports (including Linux, Windows versions, OSX, and even Android). There is no a single solution, as different OSes uses different schemes from this point of view. My longer term plan to avoid this miss, and if Xemu can't find some file there which is needed, then it would offer to download for the user right after the first run of Xemu simply. Including the kickup and SD-card image itself too. However I still want to keep the method to be able to override these as for developers, it can be useful to control everything at their own.

Xemu also contains a built-in ("embedded") KS in the executable itself, if everything goes wrong, and no KS can be loaded.

The SD-card image things comes after these steps only! So it does not help if you have KICKUP.M65 file in the SD-card *only* (but please read further!) as KS needed ot be run to recognize the SD card already. However, KS can upgrade itself form the SD-card if it founds the KICKUP.M65 on the SD card (and "SD card" in case of Xemu always means the SD card image file, while it's the real SD-card in case of the board, of course). However I felt this a bit problematic as a potential show-stopper for beginners. So I've decided to embed some KS into the Xemu binary itself just in case.

But the key information here, that KS should be get somewhere BEFORE the SD-card phase, it's true for both of the board and Xemu as well of course! The KICKUP.M65 on the SD card/SD card image file is only the *second* phase after this.

Xemu's question about "upgrade" is simply from the KS itself. Ie, if KS founds KICKUP.M65 on the SD-card (it's true for both of Xemu and the real M65!) it queries a simple I/O location to get to know it it was already upgraded. It's for avoiding the "infinite upgrade loop" I told about already (ie: an upgraded KS founds KICKUP.M65 on SD-card again, upgrades itself, starts again, it founds again ... etc, so you can see). The only "feature" of Xemu over the real M65, that, if Xemu detects some reads that I/O location to query the upgraded status, then it won't answer, but stops emulation and presents that question box, so it allows for the user to choose.

"Already upgraded ..." means that Xemu will tell to KS that it's already upgraded, so KS won't upgrade itself from the KICKUP.M65 file found on the SD card image.
"Not upgraded yet ..." means, that Xemu will telll to KS, that it's not upgraded that, so KS likely should upgrade itself from the KICKUP.M65 file found on the SD card image.

Please note, that "found on the SD-card image" is nothing to do with the Xemu, it's the KS which founds it or not, and it's nothing to do with the KICKUP.M65 found by Xemu elsewhere than the SD-card image, it's another phase (before the KS runs at all).

Well, hopefully I could answer. I'm sorry, but my limited "perfection" in English always makes me thinking that I am understandable at all, so maybe I just "over explain" myself again and again with the hope that it's more understandable that way. So this is the only reason of my style, it's far from being any ideas that I may found the other "dumb" to be able to understand, here just I am the dumb that I don't know English well enough to be more precise, shorter, etc etc :)

- Gabor

[LGB Gábor Lénárt]

Hi,

SDL2.0.4 was my choice since there are minor API differences compared to earlier versions. But the major decision is made, because I should work sooner or later on better audio support, and the "push method" for audio was introduced in 2.0.4. I didn't want to always change the minimal required SDL versions, so I've decided 2.0.4 (as the minimal) is a good choice, as most Linux distributions also supports that via their package management. Well, since I've never used Windows (really ...) I can't tell anything about Windows issues etc .. I try to be "Windows friendly" a bit, to support native Windows builds as well (with cross-compilation on Linux). I also make binary releases from time to time, though I can't check their quality, you can find them here btw: https://bintray.com/lgblgblgb/generic/xemu#files

So in nutshell: I bumped version check from 2.0.2 to 2.0.4 because of support on major Linux distros (and btw even OSX via homebrew), one of the Xemu emulator targets which need it (ep128, Enterprise-128 emulator), and also because of the plan that soon I will need functions simply didn't existed (not even similar!) in older versions, namely the push-audio support. Currently, if you don't use the ep128 emu, indeed you can do a light hack on the Xemu source to be able to be compiled even with (I think) SDL 2.0.2. But it will change. So to be clear: I didn't bumped the version needs of SDL just for fun :) but because I really need and especially will need it in the future.

However, though SDL provided a kinda great abstraction on the OSes, there are still problems. For example, native Windows exe releases can't support M65dbg. This is because Windows is strange not supporting kinda standard stuffs, supported by about every other OSes, like for example UNIX domain sockets (please note that Windows TCP/IP stack comes from BSD UNIX actually - as far as I know, even Winsock interface is kinda UNIX'ish sometimes still -, so it would be nice to have support at least). And m65dbg and xemu's m65 emu would interact over a named socket, exactly. Surely, you can try to bridge this problem with an environment like cygwin, but honestly, since I don't use windows, I have no experience with this. Usually this is not a problem, with audio/video everything should be fine by using SDL API. However networking or any IPC now is kinda not covered ... I can try to revert the stuff for using normal TCP sockets and adopting SDL2_Net library ... However using TCP sockets is a bit more problematic and maybe even slower, and also introduces another dependency for all supported Xemu OSes, since SDL2_Net is another library, not the core part of SDL2. It's an interesting question that Xemu+m65dbg should be supported in native Windows builds (not cygwin etc, native). The some goes for the future, ie with M65 ethernet emulation support ... Here even SDL2_Net wouldn't help since it requires truly low-level network stuff interaction and my only Windows programming knowledge is actually because emulators by using cross-compilers :) However don't misunderstand me, it's fun to get to know more on Windows, though I am stlll not a Windows user, you can see :)

m65dbg had only a minor patch from me in the mega65 repos, that adds only the domain socket connecting thing, so you can connect it to a real serial port (for M65 board) and also the socket-based stuff for the emulator.

- Gabor

[LGB Gábor Lénárt]

Hi Ben,

I'm sorry to "advertise" everywhere, but it's rather important to use my repo not the one from mega65 project for xemu, as the mega65 is usually much older.

You're right no need for gtk3 (for ep128emu target only). In fact, the recommended compilation method of Xemu is not saying 'make' in the top level directory, but "cd" into ie targets/c65 (or targets/mega65 etc) and say "make" there! Since then, only the required emulator will be compiled! Much faster, and also you may avoid some extra dependency (like gtk3) required some other emulator you don't even need.

[Paul Gardner-Stephen]

Hello,

Can I suggest that you make the emulator mirror the M65 behaviour by default, i.e., allowing one update to kickstart.  Command line options could be added to always prompt, or to never prompt, to support various work-flows.

Paul.

--

[LGB Gábor Lénárt]

Hi Paul,

Actually this is the situation, the -kicked CLI switch is already there with basically three possible values, zero or non-zero and the special meaning of 128 to ask, so it's only about the default value of that setting. Now the default value (if you don't specify the switch on the command line) is 128. So I guess, I need only a single line change to make everyone happy :) to set the default value to zero. That is, KS will detect not upgraded yet, and anway it will set upgraded state then, as it was with the board. Some still set the -kicked option to other value to avoid this, or even to 128 to signal the question box. You're right for _most_ people it's rather disturbing factor, and if someone needs it, it can be still asked via the command line! Thanks for your suggestion, I always say that it's nice to have feedback as maybe my opinion is far from the "average" user or even developer, it's useful to hear other's opinion on features, bugs, whatever. It will be committed soon to my usual repo.

On Friday, January 27, 2017 at 10:21:43 PM UTC+1, Paul Gardner-Stephen wrote:

Hello,

Can I suggest that you make the emulator mirror the M65 behaviour by default, i.e., allowing one update to kickstart.  Command line options could be added to always prompt, or to never prompt, to support various work-flows.

Paul.

 
- Gabor

[Gurce Isikyildiz]

Cheers Ben,
Thanks for pointing out not needing gtk3 and sharing your docs on the matter.
Gurce

[Gurce Isikyildiz]

Hi Gabor,

Thanks for your response, and not to worry about its level of verbosity and I do appreciate the time and effort you took to explain your perspective.

I have read over your response a few times to let its meaning sink into my mind a bit better. Given that, I'll try to refine my previous bullet-point list of how things flow to reflect that new understanding (in blue).

• Xemu emulator begins running
• Default kickstart code runs

• On the Nexys hardware: this is a copy of kickstart that was built into the bitstream.

• In the xemu emulator:
  - your pc's various preference folders are scanned for a copy of "KICKUP.M65"
  - if found, this is the kickstart code that will be used initially as xemu boots up
  - if not found, then xemu will boot up with the copy of "KICKUP.M65" that got compiled in the xemu binary and show this popup
   
• Kickstart then tests itself (via an "already_upgraded" flag) to decide if the presently running kickstart code is the initial one from boot-up or an already upgraded version.
  
• On the Nexys hardware:
  - If this is the initial version from boot-up (i.e., already_upgraded == false), then the SD-Card is searched for any existing "KICKUP.M65" file.
  - If one is found, this copy is loaded into memory, the already_upgraded flag is set to true, and we run this new copy of kickstart.
  
• In the Xemu emulator:
  - Upon xemu detecting a read of the already_upgraded flag, it displays this popup:
  
  - This gives the user the opportunity to dictate what this flag's value is at startup.

• "Not upgraded yet, it can do it"
  

• - This sets the already_upgraded flag to false
  - This means that the currently running kickstart will assess your sd-card image (which was my "mega65.img" file)
  - If your sd-card image (mega65.img) contains a KICKUP.M65 file, it will be made use of, the flag set to true, and it runs your new kickstart
  

• "Already upgraded, I test kicked state"
  

• - This sets the already upgraded flag to true
  - So this seems to be a good way to enforce the use of an external copy of KICKUP.M65 that you provide in one of the preferences folders, and ignore/avoid the use of any existing KICKUP.M65 files existing on the sdcard/mega65.img.
  - I kinda get this now, as adding a new KICKUP.M65 inside the mega65.img is a bit tedious (the need for mounting the image first), and using an external file is more straightforward than this.
  

Also, with this better understanding, I think I can understand what the button text is trying to convey better now:

"Not upgraded yet, it can do it"

Is really:

- Kickstart has not been upgraded yet, it (the kickstart code) can do it (the upgrade check for "KICKUP.M65" on the sd-card image)"

This is what I was trying to get at with my prior question on "it(1) can do it(2)". I've always found the word "it" a bit dangerous when it comes to sharing understanding, because the writer is hoping that the meaning of "it" will be obvious to the reader (or atleast implied by context). But on many an occasion, it isn't as obvious to the reader as the writer had hoped, leaving the reader wondering, "what is 'it'?"

Some of this text still puzzles me a little:

"Already upgraded, I test kicked state"

- Kickstart has already been upgraded, I (???) test (???) kicked state (i.e., the already_upgraded flag)

Who is the "I" referred to here? I pondered two possibilities:

a) Is "I" the person using the xemu program? E.g., perhaps is it saying "I am the user of the xemu program, and I have tested that the KICKUP.M65 I have provided is the kicked state that I prefer, so don't bother letting kickstart try to upgrade it to the one on the sd-card image"
b) Is "I" the xemu/kickstart program itself? E.g., perhaps is it the kickstart program trying to tell the user, "Hi, I am the kickstart program, and I am going to do this!"

I promise you that my goal here wasn't to be overly critical of your English/Grammar, but more to share with you the difficulties I was having in interpreting the meaning of these buttons initially, so that we could perhaps ponder some better wording to use in future that hopefully can convey your intended meaning better.

Regards,

Gurce

[Gurce Isikyildiz]

Hi guys,

Also, the reason why I wanted to get a clearer understanding of what those buttons did was because I was hoping it would shed some light on a problem I was experiencing with xemu & the disk chooser program.

If I selected the "Not upgraded yet, it can do it" button, and then did "GO64" followed by "SYS 49152" (for the disk loader menu), then I see this error:


ERROR: SDCARD: SEEK: invalid offset requested for reading[SD] with offset 1075080704 PC=$96E4

If I boot-up and select "Already upgraded, I test kicked state", it uses the default/built-in version of KICKUP.M65. I do "GO64", then "SYS 49152" and then the disker chooser program works fine.

So I guess this is telling me that the version of KICKUP.M65 found in the sd-card image (mega65.img) was at fault on this occasion?

I've noted in my logs that I got my sd-card image (mega65.img) from a download on your web-site on 27/11/2016 via:

wget https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/sd-card-image-for-xemu-xmega65.img.gz

Perhaps it was a very old KICKUP.M65 that is no longer compatible with the latest xemu mega65 emulation?

I'll try download it again in-case you've got a newer image there with an updated KICKUP.M65 file on it.

Regards,
Gurce

[Gurce Isikyildiz]

I've tried this newer mega65.img with the "Not upgraded yet..." button, and it still crashes in the disk-chooser menu. So I want to assess what the exact version of each kickstart is:

• in-built is:
  KICKSTART V00.05
  GIT: DEVELO, A9FD247+DIRTY,0923-1706
  - This is a git commit from 31/08/2016
   
• new "mega65.img" (downloaded on 31/01/2017) has:
  KICKSTART V00.05
  GIT: DEVELO,17D1BB9+DIRTY,0831-0107
  - This is a git commit from 30/08/2016
   
• old "mega65.img" (downloaded on 27/11/2016) has:
  KICKSTART V00.05
  GIT: DEVELO,17D1BB9+DIRTY,0831-0107
  - This is a git commit from 30/08/2016

 

Aah, ok, no change between old and newly downloaded mega65.img in relation to kickstart version...

 

Also, these two commits mentioned above are right next to each other in the gitk log-view, with the commit change relating solely to bash script files. Hard to imagine how that would affect the contents of KICKUP.M65...

 

I feel like I should extract out the KICKUP.M65 file from the "mega65.img" sd-card image and diff it against the default/built-in version to see if they are identical or differ...

If they differ, then, ok, maybe the cause could be due to a faulty KICKUP.M65 of some sort... But if they are the same, perhaps it would imply that there is some difficulty/issue in loading the KICKUP.M65 file from the sd-card image?

Anyway, will keep digging...

Gurce

[Gurce Isikyildiz]

Ok then, I've compared the built-in "rom/KICKUP.M65" against the file within the sd-card image (mega65.img)...

 

Hmm, I saw more changes than I expected... I honed the screenshot on a more glaring difference. The sd-card's copy (older?) has a string "RE-TRY IMG TO READ MBR" whereas the built-in "rom/KICKUP.M65" version (newer?) doesn't.

 

I'm not sure what's going on here, the git commit history can't explain this difference.

Gabor, do you have any memories of which version of KICKUP.M65 you added to the sd-card image? Was it perhaps a very old one that no longer works with the latest emulator?

Gurce

[Gurce Isikyildiz]

Perhaps as a last test, I can try extract out the KICKUP.M65 from the mega65.img sd-card image, and try load it at initial boot-up of xemu (by dropping the file in one of the sdl preferences folders) and see if it works that way

• If it doesn't work that way, then ok, I feel safe in faulting the file itself.
• If it works there, then it implies that there must be a problem loading up the KICKUP.M65 from within the sd-card image (mega65.img)

Let's see then...

• I've copied the sd-card image's KICKUP.M65 file into xemu's base folder.
• I run xemu, and the console output confirms the desired KICKUP.M65 file has been loaded:

• Trying to open file "KICKUP.M65" as "./KICKUP.M65" ...
  

• OK, file is open (fd = 5)
   

• The startup screen confirms that it is booting up with the older version of kickstart that I wanted to test with:
  
   

• I choose the "Already upgraded..." button, to assure that we continue booting with this kickstart, and not try locate and use the one on the sd-card image
   

• I do "GO64" and "SYS 49152"
   

• Aah, this still causes that same error message:
  

 

Ok then, this is looking like more definitive evidence that the KICKUP.M65 file on the sd-card image downloaded from Gabor's github site isn't working so well the latest xemu.

Gabor, if my chain of thought is sounding convincing to you, it might make for a good case to upgrade the version of KICKUP.M65 you provide within the sd-card image on the github site.

Still, I won't be too hasty in my conclusions, as you might have more of the backstory to share on these matters and reveal aspects I'm not aware of.

Gurce

[LGB Gábor Lénárt]

Hi Gurce,

Okey, some posts from you (don't misunderstand me, it's great to have feedback), I try to answer :) First of all the invalid offset problem. As far as I can remember there was some KickStart bug actually I helped to track down in relation with FAT32 filesystem handling in hypervisor DOS. Now I am a bit unsure why you see this. Maybe it's when you run an older version of KickStart (it's not important if the source of the KS is the built-in one from Xemu, the loaded one from preferences directory by Xemu "pre-boot-time", or the upgraded one from the SD card image). It's also kinda important to use my repository for Xemu, and not from github.com/MEGA65/..., as my one contains newer version and I may fixed some things in relation of this too. Honestly I feel a bit bad now, since I *do* remember I have similar problem what you demonstrates here, but it was kinda "some time ago", and I am not sure now what it was :( One thing came into my mind: it's maybe this problem:

https://github.com/MEGA65/mega65-core/issues/20

Also I had this report: https://github.com/MEGA65/mega65-core/issues/17

But it's a request to add a check, and that wouldn't solve the problem itself, only allows the HypervisorDOS itself to "panic" so it can be clearly seen there is a problem there, and it would even help the board, where you won't have some dialog box like in Xemu to telling invalid seek offset, I guess, so it's harder to tell there what's the problem. But actually I've used Xemu already to try to find bugs in KickStart, this one: https://github.com/MEGA65/mega65-core/issues/21

One thing: it's totally possible that I use kinda old KS somewhere which causes problem (or problems), some possible places:

1. The xemu's built-in kickstart
2. The one you mentioned inside the downloadable SD-card image file: https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/sd-card-image-for-xemu-xmega65.img.gz
3. Maybe the problem there is a problematic KS loaded by Xemu from the "preferences directory".

As these are the three possible sources of kickstarts in Xemu. Let's see then, when you use these actually:

1. built-in kickstart used _initially_ if kickup.m65 cannot be loaded from you host OS filesystem, from the preferences directory ....
1.a.) till the point, you allow KS to upgrade itself (this is the infamous dialog box in Xemu ....)
1.b.) or if you don't allow KS to be upgrade itself, then 1. is continued to be used
2. The KS can be found on the SD-card image file upgrades the "boot KS" if you _allow_ KS to be upgrade itself (that dialog box again), if you dont' allow, it won't be used for sure at all
3. This is almost like the point 1., except, that actually this is tried first by Xemu, then point 1. The a/b cases are similar here (note that either point 1. or point 3 will be considered but not both, still 2. can be an issue, since that is the "post-SD-card" phase of the boot, if I can say that)

Let's clear one thing: in my Xemu repository, there should :) be a version ALREADY which does not present that ugly "upgrade KS dialog box" at all. However report me, if it does not work or there is some issues ...Thanks. You can still ask Xemu to that via command line of Xemu/mega65, the -kicked option. Possible values are:

-kicked 0    ---> this means, you _allow_ KS to be upgraded from SD-card. Now this is the default, as this is what the board does as well, kinda logical suggestion from Paul some posts ago in this thread, what makes sense!
-kicked 128  --> the old default one: show a dialog box, and allow the user to decide ... but it seems it created more problems and questions what it would solve :)
-kicked 255 --> do NOT allow KS upgrade ...........

Actually there are more possible values, but kinda useless, since other values should mean the same as 255 (however still, this part of Xemu is kinda ugly currently ...) If someone is not familiar with Xemu command line, it can be useful to use the "-help" switch to get the list of available options, though, I have to admit, this can be too short for documentation and would need a longer description in the future ... My other plan with the command line parser stuff, that it will be re-used for configuration parsing as well (the framework is there already ...) so you can even use settings with your favourite defaults in form of config file for Xemu (even  like things starting in fullscreen mode, and such ...). Actually the "already_upgraded" flag (as far as I understand) for the board, is 0 zero if not upgraded yet, and 255 if so. That wants to be my values above 0/255 with -kicked option. 128 is special, and it's only an "artificial" value especially for Xemu to ask that dialog box :) It's a non-standard value, we can say! Anyway, the important factor here, that if KS sets already upgraded flag it's always set to 255 then regardless of -kicked option (or after the dialog box, based on the choice ...) so it's kinda "initial value" only, the KS still needs to know, not to stuck into infinite-loop to try to upgrade itself again and again. So, for example -kicked 255 only does to set that flag to "yes" (already upgraded) so KS is "fooled" to think that it already upgraded itself, that is, avoid upgrading :) And 128 you see will cause either 0 or 255 to be set _based_ on your choice in that damn dialog box :) :)

I'm not sure if it's really important to talk more about this KS upgrade topic, as the default in Xemu now (from my repo, again!) is not the dialog-box based horror of choices any more, unless if you override the setting with -kicked command line option.

The other thing, what I've already mentioned: my plan is to allow Xemu to download things as its own (surely, prompting user first for permission: I don't like software trying to do something with the net without my permission first ... especially if it's not a network related application at all). This would be good, because:

* allow even non-tech users to use Xemu without *any* downloaded ROM image, kickup, sd-card image, whatever, you name it
* in case of an upgrade something which could be downloaded, it can be updated by Xemu then from the network maybe (?)
* things like built-in KS in Xemu is *ugly*. And makes things harder to understand as we have THREE sources for KS in Xemu, and only two with the board. However I wanted this, since if you don't have kickup.m65 file in your preferences directory of xemu/SDL, then it won't work at all. With allowing Xemu to download things, it can be done easily with only one external KS (and one SD-image-insider KS, if you have/want that). And this allows to update version of "xemu-KS" which in case of built-in, would mean to change the .exe file of Xemu (in case of Windows, or similar for Linux/OSX, so the xemu executable binary file itself).

And yes, you're right, it's kinda possible that the SD-card image file you mentioned as well is too old, and should be updated, at least the ks on it :) And thanks for noting it, also to spend time to track this down, actually.

- Gabor

[LGB Gábor Lénárt]

Btw, one other important point ... If someone can/want/whatever to build a "cool" SD card image file for Xemu which really works :) with maybe extra softwares, whatever, please do it :D I try to find time soon to update the SD image file though. Btw, one solution can be, to actually *delete* kickup.m65 from SD-card. As for most users, it's (I guess) more comfortable not to upgrade SD-card image always just because KS, especially if KS can be "fed" from outside by Xemu. (however for sure, KS upgrading is important for developers, that's another thing).

- Gabor

[Ben-401]

Yes, i will try and create a "cool" sdcard image called mega65.img
refer to thread: https://groups.google.com/forum/#!topic/c65gs-development/ADtUee0DGOk

Please note that the KICKSTART v00.05 is really old, yes from AUG-2016.
Throughout SEP-2016, significant updates were made to the FAT32/SDCARD stuff:
- Paul implemented a number of FAT32/sdcard fixes to the cursorkeys branch. These fixes were cherrypicked and put into 'development' branch on 20-SEP-2016.
- Ben created documentation on FAT32 and SDCARD, and updated KICKSTART to output meaningful information.

In this regard, please use kickup with version 06 or greater, as suggested in
https://groups.google.com/d/msg/c65gs-development/D-m-VeUHWBI/pyIb_Y_fAQAJ
The current version of KS is v00.09.

The log-history on the "kickstart.a65" file shows that on 26-SEP there were further chages to the way that KS implements the End-Of-Directory marker.

[Ben-401]

also, the KICKSTART outputs debug messages of SWITCH-12 is asserted.
the xemu can be configured to output these messages using the following
"./build/bin/xmega65.native -fpga 12"

Well done guys. We are getting there...!

[LGB Gábor Lénárt]

Hi Ben,

Yes, some time ago there was a compile time #define stuff in xemu/mega65 to be able to "configure" the emulated FPGA switches. But it required to recompile Xemu ... So when I implemented some framework to allow to use command line switches, I included support for doing that with the -fpga switch instead. One thing that Xemu is much slower when enabled. This is because KS is "hardcoded" with original timing to delay sending information for the serial port timing, and currently xemu emulates only the ~3.5MHz clock speed. The solution would be (other than also trying to make xemu faster ...) the "UART ready bit" at FPGA level too, ie, the hardware would report when it's OK to send something again over the serial connection. So the very same KS then on the board will honour that bit for waiting, but Xemu would "fake" information that it's always ready, since serial port timing does not exist for real in case of the emulator. This is the issue page on this: https://github.com/MEGA65/mega65-core/issues/23

About FAT32 handling: indeed there was some EOC issue with hypervisor DOS / kickstart problem I've managed to identify with the help of Xemu, this may or may not a problem with especially other OSes than Windows while touching the SD card or SD card image with Xemu and also the real board for me, at least. This is this one: https://github.com/MEGA65/mega65-core/issues/20

My concern with newer KSes btw, that as far as I can see, Xemu now reports that KS tries to access memory right after the byte after the hypervisor RAM area, causing an "Xemu panic". It didn't happened with older KSes hmmm ....

[Gurce Isikyildiz]

Hi Gabor,

Thanks for your post, I've read it a few times, trying to let all the details sink into my brain. I won't have the time tonight to give a full response, as I've also been doing more detective work on my side about why things went wrong for me. Still, I can share a few points:

• As to regards to which repo I'm using, yep, I can assure you that I switched to your repo about a week or so ago.
  - One possible gotchya in my mind is that I did this by edit the ".git/config" file, changing the url in there to your path, and then doing a git pull.
  - Now I worry if this caused debris from my prior build of the old mega65 repo to loiter about and mess up my latest build
  - Perhaps I should just do a fresh clone of your repo to rule this possibility out
• Yep, I followed your response to Paul on his suggestion to make the default boot-up behaviour to be "-kicked 0" instead of "-kicked 128". And yep, that sounds good to me too. Still, a part of me wanted to assess and study the issue I was struck with, so I haven't upgraded to your latest xemu version yet (but I will after I get my head around this present problem I have :)).
• I'm agreeing with your thought that we should delete the KICKUP.M65 from the sd-card image (mega65.img). I'm suspecting it is old, as I assessed its age in the earlier post:

• new "mega65.img" (downloaded on 31/01/2017) has:
  KICKSTART V00.05
  GIT: DEVELO,17D1BB9+DIRTY,0831-0107
  - This is a git commit from 30/08/2016

• So thanks Ben for offering to make the next "super" sd-card image :) Hope you can delete that KICKUP.M65 file off it in the process

Regards,
Gurce

--

[LGB Gábor Lénárt]

Hi Gurce,

Well, the commit date of the SD card image file of mine can be misleading. Sorry, I can't remember now, but it's highly possible that the image actually even more old than the upload date, and I used that for a while to test Xemu, and just later I decided to upload it, so others don't need to bother too much to create their own image files to try Xemu. So an update is not exactly a wrong idea, but the opposite :D

Now I have an issue with this, though. It seems newer KSes does not include the disk mount image utility, what you would use with SYS49152 in C64 mode. So the question, that should I update the SD card image file on-line what a much more up-to-date KS but without that feature?

About editing files in .git/ ... Well, honestly I am far from being a GIT wizard, so I am not sure what it would cause ... I'm more or less okey with simple commits, stuffs like that, but that's about all :)

And (if I haven't mentioned yet, sorry if i did ...) one other thing: the commit data of my disk image file on-line can be misleading. I don't remember now, but it's highly possible that it's even older than that date, and I had already used that image for myself to test Xemu etc for a while before I made it available by committing it, so others don't need to bother to make an image file just to be able to try Xemu ...

- Gabor

[Ben-401]

Hi Gabor,
Minor success, but...
some dialogs still show FATAL "Unhandled memory operation linear address" dialogs.

Can these dialogs please be "DEBUG" with a CLI option to switch between FATAL and DEBUG?
I have modified my local version of lgblgblgb/xemu to hardcode the FATAL to DEBUG in 2x places, lines 894 and 962 of file "targets/mega65/mega65.c", and this allows the xmega65 to continue to the screen.

Yay, we can now load programs into the C65 and C64 using your emulator.
Ben

ps, i think its best you add the CLI switch instead of me forking, patching, pull request, etc...

[LGB Gábor Lénárt]

Hi Ben,

The unhandled fatal stuff in newer KS'es is because KS does a too long DMA "runs out" of hypervisor memory. That should be fixed in KS. After I did some inspection on KS/DMA what it did it seems KS does a fixed $1000 long DMA to copy the SYS49152 stuff into the memory which is just too long. It seems newer KS'es - according to Paul - does not include the SYS49152 stuff (okey, somewhat silly name from me, so the disk image mounter stuff you can start with SYS49152 in C64 mode, what I meant here) because it would be too big. Surely, we can say, that undecoded memory area read/writes can be simply ignored, but it is exactly a great feature of Xemu to catch problems with KS actually remaining "hidden" with the board as it won't signal the problem.

Try in kickstart.a65 modify this part to this way:

diskchooserstart:
        ; Pre-compiled disk menu
        ;.incbin "diskmenu_c000.bin"
        .byte 0  ; LGB: but here something, since .incbin is commented out, so diskchooserend-diskchooserstart as length would be zero, resulting 0 for DMA length meaning 64K transfer. Surely with non-zero sized incbin here, it is not needed
;       ========================
                .checkpc $BB00
                .advance $BB00
diskchooserend:

And then:

copydiskchooserdmalist:
                ; also copy diskchooser from $FFFE000-$FFFEFFF to $000C000-$000CFFF
                .byte $00 ; copy + last request in chain
                .word diskchooserend - diskchooserstart ; LGB, was: $1000
                .word diskchooserstart ; source address
                .byte $0F ; source bank
                .word $c000 ; destination address
                .byte $00   ; destination bank
                .word $0000 ; modulo (unused)

And recompile KS. Actually the line above "LGB, was $1000" meant to be the fix, since the default $1000 is just too long. Anyway as you can see, from the first place, .incbin is commented out, so the disk mount util won't be compiled in.

But you're right, it can be an option to provide a CLI switch to ignore unhandled memory accesses without panic in Xemu anyway, though it's still true that in my opinion KS should be fixed here, and as you can see, this actual problem and Xemu's "panic" helped me to find this KS problem out would be hidden without this Xemu "feature" ...

[LGB Gábor Lénárt]

Hi Again :)

But anyway, here it is a patches KS version in compiled form attached, which eliminates the unhandled memory problem.

Anyway, I've just committed a change which introduces this CLI switch for M65 emulation in Xemu:

-skipunhandledmem

In theory :) it should do to make this unhandled memory access "panic" as a warning only, with ignoring the memory write, and faking $FF as read in case of unhandled memory access. However, I strongly believe that a panic like this should be always tracked to find the problem out (let it be a KS problem, or Xemu-level emulation problem, or whatever), instead of "fixing" it with just ignore the problem like with the CLI switch option above, which only hides some problems somewhere leaving it unfixed ... :)

In theory there is even more checks like that in Xemu, for example out-of-hypervisor memory execution outside of hypervisor memory, that was not touched by this commit (that checks allows some execution outside the hypervisor RAM though, needed for KS upgrade).

[Ben-401]

Hi,
We have just updated our MEGA65/xemu to be in sync with your lgblgblgb/xemu.
Paul asked me to implement the CLI option, and make a pull request (opposed to asking you to do this change).
I have since forked the MEGA65/xemu, attempted to make the CLI change, commit, push, pull-request to MEGA65/xemu.
Since you have done this CLI change, I guess we can reject my pull-request.

I agree that the xemu has this powerful feature of finding out-of-bounds errors.

Thanks for your fix to the DMA code. I have never understood that part yet, so maybe now it will become clear how it works.
A recent commit by Paul (c37d14d4e7e56) made changes to the "copydiskchooserdmalist", and it seems this part of the KS has been removed now.

[LGB Gábor Lénárt]

Hi,

Well, sorry about that, I've just read your posts here, so I've decided to implement a feature like you suggested for optionally skipping this panic stuffs. When I wanted to check travis status out for build-test etc, then I only discovered you made a pull request already. Btw, this is also one of the reasons, I told already we shouldn't have a forked xemu repository which basically either the same as mine, or usually much older version of mine ... Since it's possible to drop a PR to my one directly too, and it's kinda confusing this way sometimes ...

[Paul Gardner-Stephen]

Hello,

Thank you both for being very gracious through this -- it always makes everyone's lives much nicer and more fun.

As for remerging to a single repository, this would be great.  I would prefer that we transition to the mega65 being primary, with you LGB, as the admin of it, so that all the M65 related stuff has its authorotative version in one place.

Paul.

On Fri, Feb 3, 2017 at 6:39 PM, LGB Gábor Lénárt <lgbl...@gmail.com> wrote:

Hi,

Well, sorry about that, I've just read your posts here, so I've decided to implement a feature like you suggested for optionally skipping this panic stuffs. When I wanted to check travis status out for build-test etc, then I only discovered you made a pull request already. Btw, this is also one of the reasons, I told already we shouldn't have a forked xemu repository which basically either the same as mine, or usually much older version of mine ... Since it's possible to drop a PR to my one directly too, and it's kinda confusing this way sometimes ...

--

[LGB Gábor Lénárt]

Hi Paul,

Well, I has been just thinking on the topic you wrote about here, as well. My main concern about moving to a mega65 repository primarily is the fact that Xemu is a multi-target emulator "framework" so many other emulators exist (and more will come) in the future. Surely, nowadays my main works are about mega65/c65, that's true, indeed. However then it can be confusing to get commits/etc for totally m65/c65 unrelated stuffs. Actually one can say it would be better to split the source to have a c65/m65 only emulator, and the rest of the emulators, it would actually made things even more complex. This is because then I need to do every Xemu project/framework related tasks in two separated source tree :( And actually other emulators (let it be the Z80 based Enterprise-128 emulator or other in Xemu) also can help the c65/m65 emulators from time to time, since the global Xemu level "framework" can be evolved by the needs of other emulators too which can be a win for c65/m65 then. Even currently many features were backported from the Xep128 project, which was a separated Enterprise-128 emulator once, and I am still working on it sometimes to unify the solutions so even m65/c65 emulators can benefit from these works. Well, my English problems always make that harder to be express myself, but hopefully you get the idea. I think, it's maybe even better (though not ideal) to keep things as currently (ie, having two repositories).

[Paul Gardner-Stephen]

Hello,

Understood. The other option is to just always pull and update the mega65/xemu repo whenever you push to the other. In fact, you can easily add a 2nd origin to git to make this very easy to do.  How does that sound?

Paul.

On Fri, Feb 3, 2017 at 6:55 PM, LGB Gábor Lénárt <lgbl...@gmail.com> wrote:

Hi Paul,

Well, I has been just thinking on the topic you wrote about here, as well. My main concern about moving to a mega65 repository primarily is the fact that Xemu is a multi-target emulator "framework" so many other emulators exist (and more will come) in the future. Surely, nowadays my main works are about mega65/c65, that's true, indeed. However then it can be confusing to get commits/etc for totally m65/c65 unrelated stuffs. Actually one can say it would be better to split the source to have a c65/m65 only emulator, and the rest of the emulators, it would actually made things even more complex. This is because then I need to do every Xemu project/framework related tasks in two separated source tree :( And actually other emulators (let it be the Z80 based Enterprise-128 emulator or other in Xemu) also can help the c65/m65 emulators from time to time, since the global Xemu level "framework" can be evolved by the needs of other emulators too which can be a win for c65/m65 then. Even currently many features were backported from the Xep128 project, which was a separated Enterprise-128 emulator once, and I am still working on it sometimes to unify the solutions so even m65/c65 emulators can benefit from these works. Well, my English problems always make that harder to be express myself, but hopefully you get the idea. I think, it's maybe even better (though not ideal) to keep things as currently (ie, having two repositories).

--

[LGB Gábor Lénárt]

Hi,

That sounds reasonable. After all when I figure out how this works. Now I tried to study git, reading many question-answer like pages etc, now I can only got (after trying to set another remote up), that I cannot push *anything* since cryptic GIT errors I can't even know what means :( Maybe I re-create local copy of mine, since it's totally messed up. GIT is awfully complex for me :( But well, it's the situation for everything before we learn and understand it :)

[LGB Gábor Lénárt]

Hi All,

https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/sd-card-image-for-xemu-xmega65.img.gz

Updated. KICKUP.M65 has been **deleted** from the image, as it makes hard to update KS for Xemu with default settings as it would cause to upgrade itself from SD card, which is usually older than you can supplied from "outside of SD-card" for Xemu (the situation is opposite for the board: then it's maybe more easy to put new KS on the card and not to update the bitstream itself if possible). Other than that, C000UTIL.BIN is added, so new KS can load its "SYS49152 mount thinggy". MEGA65.D81 is also updated.

I think, for most users, on the emulator side (not the board!) is more easy not to have KS on the SD card image at all. Surely if some wants to test exactly that, can use their own SD card image.

Surely, a KS (if possible a new one) should be provided for Xemu to be able to work. I would be able to simply update Xemu's built-in one (in the source), but I don't want to do that, unless some other can check it out as well, if this is OK this way too. For that check, it's needed to provide a KS for xemu/mega65 either in the standard place (SDL/xemu preferences directory) or anywhere, given by the -kickup command line switch (followed by the path+name of the KS, for sure).

For longer term, I have some ideas, like to allow to specify a **directory** for the -sdimg option. In this case a future Xemu would be able to construct the correct SD-card image file as its own from files under that directory. So then, it's kinda much more fun, to put things for Xemu on the SD card image, rather than dealing with "image files" all the time, which is much more complicated. Anyway, in theory, it's possible to mount the SD card image file (on Linux at least, no idea about other OSes), like this:

sudo mount -o loop,offset=$((2048*512)) /bla/bla/sd-card-image-for-xemu-xmega65.img /mnt/

However, in this case, only root can write image, and anyway, it's kinda dangerous to have a mounted FS, while a software (Xemu) uses the "storage backend" of it in the same time, so I wouldn't recommend this too much.

[Paul Gardner-Stephen]

Hello,

We should start including a version indication somewhere in the kickstart ROM, so that we can avoid unintentional down-grading.

Paul.

--

[LGB Gábor Lénárt]

Hi,

Nice. I don't know if hypervisor DOS functions (what - I assume - used by KS to upgrade for newer one too) supports seeking within the file. If it does, an information block can be attached at the end of KICKUP.M65 file. Surely it can be done even if seeking is not so much OK, but then "old" KS needs to load the full KS to get the info block, and I am thinking if it's better to put then to the beginning. Surely it would enlarge KICKUP.M65's size but info block is only info. It can - for example - contains a 32 bit version counter which is more than enough but maybe even textual information or whatever (source of KS, comments, devel info or such), but surely not in a too big size after all. Well, it can even starts with some ID byte sequence just to be sure it's really a KS and not only some invalid file named KICKUP.M65 (or even a checksum included to check integrity?) causes "crash" then after upgraded to. I have no idea if these ideas were useful at all :D

[Paul Gardner-Stephen]

Hello,

Actually, it is quite simple: We can have a set location for the version bytes, and the kickup process can load the new kickstart into RAM as it does now, and then compare the version bytes in that, to the ones in the one running, and only copy the new one into place if the version is newer.

Paul.

On Sat, Feb 4, 2017 at 2:38 PM, LGB Gábor Lénárt <lgbl...@gmail.com> wrote:

Hi,

Nice. I don't know if hypervisor DOS functions (what - I assume - used by KS to upgrade for newer one too) supports seeking within the file. If it does, an information block can be attached at the end of KICKUP.M65 file. Surely it can be done even if seeking is not so much OK, but then "old" KS needs to load the full KS to get the info block, and I am thinking if it's better to put then to the beginning. Surely it would enlarge KICKUP.M65's size but info block is only info. It can - for example - contains a 32 bit version counter which is more than enough but maybe even textual information or whatever (source of KS, comments, devel info or such), but surely not in a too big size after all. Well, it can even starts with some ID byte sequence just to be sure it's really a KS and not only some invalid file named KICKUP.M65 (or even a checksum included to check integrity?) causes "crash" then after upgraded to. I have no idea if these ideas were useful at all :D

--

[LGB Gábor Lénárt]

Hi,

Well yes, I don't know how introduced seeking at all, I was too sleepy near to the dawn here or so :) I just mentioned a well defined info block with more space that maybe store more information at a well-defined place and also do not take up precious space from the kickstart image if we do so :) Surely if only a version number must be stored, that few bytes do not count too much ....

[Ben-401]

Maybe we can use the subroutine "*_getversion" within KICKSTART to find which version we are in, and what has just been loaded?
As described in:
https://groups.google.com/forum/#!topic/c65gs-development/Fp_ZSouWNb8

Yes, the two currently embedded strings keep moving around within the memory because they are not in a hardcoded place.
If the "dos_and_process_trap_table" are in hardcoded positions, then may we be safe just calling a hardcoded subroutine to get the version?

[LGB Gábor Lénárt]

Hi,

Built-in KS of Xemu/mega65 is updated now for the latest from mega65-core development branch. Also please note the newer sd card image file I've already written about.

As from time time I usually do, there are even binary builds for xemu (for win32,win64,osx, linux deb/rpm - though I cannot test win32/64/osx, and also not so much rpm by my own, if it's really ok ...), here: https://bintray.com/lgblgblgb/generic/xemu

Note, that here windows builds are "native" ie not cygwin (actually using mingw cross-compining done on Linux). That also means, things needs UNIX/POSIX like stuffs won't work, which would probably okey, with some cygwin magic. I can mention here mainly the uart-mon interface in mega65 emulator ... (since it used UNIX domain sockets, what windows do not support natively at least). Here, my plan to use tcp socket anyway to be bound to localhost, so it will work everywhere (and also allows some extreme ideas to work through the network ...), however that will need some m65dbg patch in the future as well.

[LGB Gábor Lénárt]

Hi Ben,

On Saturday, February 4, 2017 at 1:05:30 PM UTC+1, Ben-401 wrote:

Maybe we can use the subroutine "*_getversion" within KICKSTART to find which version we are in, and what has just been loaded?

Though I am not an expert in KS internals at all, I can see a potential problem with this method. To allow KS to upgrade itself, it can't simply load it into the hypervisor RAM, since we are there to actually run the code which loads. So we definitely needs an out-of-hypervisor-RAM area for temporary to do the trick if I am right. Now, if only the loader code is this stuff, it won't help, since then hypervisor RAM is already overwritten by the time when we wants to figure out that it's newer RAM or not. The other case is more promising, when we load new KS to a place to "normal" RAM, check the version, and only copy it in the place of hypervisor memory area, if we really want to upgrade. But in this case, if you want to use an actual function (which needs code to be executed from the newly loaded, yet in the normal RAM KS) then it can cause problems, as (new) KS may assume that it's already in the hypervisor RAM area, and eg doing a MAP according to it, so it will fail. Well, I am kinda sure, you know better than me, how this works exactly :) the only reason I mentioned it, that maybe I can learn something from your response of this post from me :) Surely, I am the lazy kind here, as I would be able to see the source to figure out, how KS upgrade exactly happens :-) But the above is also a reason I thought, it's better not to execute code in new KS to figure its version out, but having some well defined data read by "old" KS without the need of code execution. Hopefully I haven't misunderstood something  here kinda badly ...

[Paul Gardner-Stephen]

Hello,

You are right, that kickstart has to be loaded somewhere outside of hypervisor RAM during the update process.  This is exactly what happens now, which can be seen by tracing the kickup code in the hypervisor.

From memory, it gets loaded at $04000 in normal RAM, and from there, if all is well, kickstart copies a little routine out into RAM, and runs that to DMA the new kickstart into place, and jump to the reset entry point.

As for the upgrade check, I would simply, after loading the possible update to $04000, read the bytes and compare them with those in the running kickstart, e.g.:

LDA $3AFD

CMP $BAFD

BCC ...

...

This would likely give the absolute smallest code size for this extra check.

While I think of it, the DMA copy routine could be run directly from the RAM copy of kickstart during the update process, which would save us the extra bytes for the copy routine for the actual copy in to place routine.

Paul.

--

[Ben-401]

I have started a thread on the kickstart at:
https://groups.google.com/forum/#!topic/c65gs-development/Fp_ZSouWNb8
maybe kickstart related development discussions should go there?

As for how the xmega65emu handles the kickstart upgrade process, I suggest that the xemu emulates the behaviour of the hardware. Ie: dont change the KS behaviour, but do change the xemu behaviour.

Can we remind our self:
why we are discussing this "changing the kickstart upgrade behaviour".
Isnt it true that we are discussing this due to the difficulty we have had over the last few weeks or so, using an old version of KS and not really knowing that it was old? Or not knowing which buttons to press to make the xemu load an alternate-version of KS.
If this is the case, I think that we have found solutions to these two issues above.

Further, what would happen if we wanted to force xemu to load an alternate version of KS using the CLI options, namely to load an older version, considering the proposed changes of KS having a check of version numbers and preventing a downgrade.

My opinion is to have xemu attempt to overwrite its internal KS using the following rules:
- only once per application initialization,
- only if the KICKUP.M65 file is found, ie seen in the SDCARD file or other working directories,
- regardless of version
The above rules are consistent with the hardware.

[Paul Gardner-Stephen]

See my comment in other thread. I now believe the best solution is to set the already kicked flag in xemu if a kickup file is provided on the command line.

Paul.

--