mega65-ide

Gurce Isikyildiz

unread,

Jan 28, 2018, 12:10:19 AM1/28/18

to MEGA65 Development

Ok, making a start on it, but slow progress, mainly reading, learning, and modest tinkering.

I made a fork of the project, and added C=b (page up) and C=f (page down). Paul suggested C=- and C=+, but I wasn't getting any cgetc() response for one of these key combos, not sure if it's because of running things on a mac.

I pondered the logic of the scrolling code, I see there is a segment within the "line.c" - line_find_offset() function that has been commented out, containing a call to line_find_offset_backwards().

Judging from the 2nd last commit to lines.c (f9d57c5c), this backwards searching was something still in progress, so I guess I'm carrying on from this effort.

I also notice though that even forward-scrolling seems a tad slow, which surprised me, considering that the forward-search for "\r\n" characters seemed to be in-place already.

I was pondering if there were any good mechanisms to debug things as the program runs. I recall hearing about how the vhdl code had hyperkernel debug output that could be seen from the serial monitor.

Would it be possible to spit out such debug info at the software level too? E.g., would I be able to create some helper function (e.g., hk_debug_out("some debug text");), sprinkle calls to it through the code and see this text over the serial comms?

In the interim, I considered just poking the screen background/border colours to act as flags, but that felt a little too minimalistic :)

Paul Gardner-Stephen

unread,

Jan 28, 2018, 12:33:46 AM1/28/18

to Gurce Isikyildiz, MEGA65 Development

Hello,

Sounds like you have found the path.

Serial output to the monitor interface is only possible from the hypervisor at the moment, by writing to $D67C, but I can easily add a hypervisor call to write to it, if you like. You are running it on a nexys4 board, right?

Paul.

--
You received this message because you are subscribed to the Google Groups "MEGA65 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.

Gurce Isikyildiz

unread,

Jan 28, 2018, 12:41:41 AM1/28/18

to MEGA65 Development

Yep, I've got the nexys4ddr board.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

Paul Gardner-Stephen

unread,

Jan 28, 2018, 12:59:43 AM1/28/18

to Gurce Isikyildiz, MEGA65 Development

ok. I'll aim to add a hypervisor trap for doing this for you.

Paul.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

Gurce Isikyildiz

unread,

Jan 28, 2018, 3:00:41 AM1/28/18

to MEGA65 Development

Cheers Paul. Not much progress at this stage, just fishing around. I also took a look at the cc65's -l listing option, pondering if I can make use of this in m65dbg at some stage to help out with this sort of debugging too.

Paul Gardner-Stephen

unread,

Jan 28, 2018, 3:49:51 AM1/28/18

to Gurce Isikyildiz, MEGA65 Development

Latest commits make LDA #$7C LDY #<char to output> STA $D640 NOP output a char to serial monitor (though it is currently untested). It is a kickstart only change, so you can just use monitor_load -k to use it, without needing to resynthesise.

Regarding the listing option, probably worth having a chat to LGB about it.

Paul.

On 28 January 2018 at 18:30, Gurce Isikyildiz <gurce.is...@gmail.com> wrote:

Cheers Paul. Not much progress at this stage, just fishing around. I also took a look at the cc65's -l listing option, pondering if I can make use of this in m65dbg at some stage to help out with this sort of debugging too.

--

Gurce Isikyildiz

unread,

Jan 28, 2018, 7:52:26 AM1/28/18

to MEGA65 Development

Thanks Paul, I couldn't see any commit related to this? Was it one that wasn't pushed yet?

In preparation, I'm also trying to get LGB's latest xemu running, it was requesting for a few files (kickup, banner, diskmenu_c000) in new locations upon startup, so I've tried to copy them across and re-start. Oh, it also offered to create a new sd-card for me, I accepted (128MB).

Upon restarting, I seem to be getting closer:

I see the "SELECT UTILITY TO LAUNCH" message, but no utilities are listed there. Any ideas where I went wrong here?

Gurce Isikyildiz

unread,

Jan 28, 2018, 4:48:38 PM1/28/18

to MEGA65 Development, LGB Gábor Lénárt

Hiya LGB,

I was trying to do some debug work inside the xemu emulator and had some trouble booting into the latest xemu (more info in the thread below from the google groups forum). Any thoughts on what I need to do?

Also, Paul mentioned you could have some insights into how to go about debugging a c64 app running inside xemu. Does the xemu emulator have any debug facilities I could make use of too?

Thanks for any help.

Cheers,

Gurce

--

LGB Gábor Lénárt

unread,

Jan 28, 2018, 5:28:40 PM1/28/18

to MEGA65 Development

Hi Gurce,

How old the kickstart you try to run inside Xemu? According to the screenshot, quite now, 20180128, that's today. Xemu does not support yet many incompatible changes done in mega65-core recently. For example, DMA operation is different, thus, currently it's impossible to use any KS in Xemu which is after that DMA change. By they way, right time you ask this, because I was middle in my project of rewriting the whole DMA stuff (the change in M65 does not need that, but Xemu's code too much bound to the old behaviour, and it has other issues as well) in Xemu when I noticed your message :) So it will work, but not currently. At the other hand, I am not sure about that, but maybe there are other needed changes as well which is problematic with newer KS'es, like the SD buffer (if I remember correctly) is another address than it was, and maybe others. Please do not misunderstand me, I don't "blame" anyone being these changes, especially NOT Paul, since eg DMA is a very nice and useful change, even if it's not backward compatible with the older M65-specific solutions. You can blame me though, that I can't be fast enough to follow his changes :)

If you have an SD-card image with a newer KS on it, it's probably that KS upgrades itself, and the new KS won't work because of the described changes. Try delete that from the image, or use the "-kicked 128" command line switch for xemu, it will cause that Xemu asks you (you can also say 0/1 for example, 128 is a special value to ask the user actually) to allow to report already upgraded state which should avoid the issue if you choose right, but however that means you stuck with the older KS what Xemu has built-in. It's a problem only, if you try to test programs with Xemu especially using these new features what Xemu does not know, though ...

About the debug features: honestly I didn't tried too much that, especially not recently, but maybe even a year ago or so :-O In theory, Xemu has some limited support for the same protocol what the "real M65" use as well with m65dbg. So you can "attach it" with that too,, simply said. You need Linux (well or any UNIX-like OS probably does, I guess MacOS too) for that, as the interface uses named pipe instead of real serial port, and I didn't know at least, if it can be done on Windows or not. But beware, it's quite old, and I am sure many commands recognized by M65 not handled by Xemu.

It's explained here, search for something says "UART-monitor" as a subtitle through the page:

https://github.com/lgblgblgb/xemu/wiki/targets-mega65

About this UART-monitor/debug stuff in general: maybe I'm boring that I always say "I will rewrite it" ;-P but it's again that the case. It will move a more platform-independent TCP socket based connection. For m65dbg it will cause some changes in m65dbg itself, but only a few lines. At the other hand, it will be a new design, also target independent, meaning a framework for all emulators in Xemu (though here, I guess, only Mega65 counts too well), and besides a totally m65dbg compatible protocol in its core, it can support HTTP mode as well (once, I started to write JS code interacting with it, which is capable of providing "platform independent GUI" - ie the web itself - debug features, like visualizing the memory content as charsets, sprites, screens, not just text based information can be easily decoded this way). But this feature is left to be open by the possibility to accept HTTP requests, now the important near-future factor of course more the m65dbg text based protocol compatibility (but in fact both of HTTP and m65dbg protocol uses the same things, just the "tunnelling" is different, if I can say that).

LGB Gábor Lénárt

unread,

Jan 28, 2018, 5:31:48 PM1/28/18

to MEGA65 Development

Ouch, I was - as usual - unaware of some facts from your posts :-O So you have a new SD-card image and allowed Xemu to create it (then it's really a new feature ...). So then the problem that you use a too new kickstart externally for Xemu, forget what I told about -kicked option and deleting KS from SD-card image etc etc. The other things still apply though :)

Gurce Isikyildiz

unread,

Jan 28, 2018, 5:56:37 PM1/28/18

to LGB Gábor Lénárt, C65GS Development

Thanks LGB, looking forward to giving it another try with your suggestions tonight.

--

Gurce Isikyildiz

unread,

Jan 28, 2018, 9:59:28 PM1/28/18

to MEGA65 Development

Just thought I'd step through with xemu and m65dbg to try see if that gave any further hints why my kickup was failing.

I tried focusing on the a65 code that related to the listing of these utilities. I see that inside "kickstart.a65", there is a call to "jsr utillist_validity_check".

It looks at the zptempv32 dword pointer (which presently equalled 0x0FF80800) and looks for the string "M65" here.

For my case, this string isn't present. I'll try learn more about this... If I do a mdump of this 0FF80800 address, all I see are zeroes here.

<dbg>mdump 0ff80800
:0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

Is this a sign that the sdcard didn't load properly? Or that the utils weren't loaded to the desired location?

Paul Gardner-Stephen

unread,

Jan 28, 2018, 10:02:39 PM1/28/18

to Gurce Isikyildiz, MEGA65 Development

Hello,

I see that the dumped address is showing as 0000000, not ff80800. Maybe that is part of the problem?

Paul.

--

Gurce Isikyildiz

unread,

Jan 28, 2018, 10:11:05 PM1/28/18

to MEGA65 Development

Oh, good point, didn't notice that earlier...

I tried using the raw serial monitor commands and noticed the following:

<dbg>d0800 (cpu-context dump)
:0000800 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00
<dbg>m0ff80800 (28-bit address)
?SYNTAX ERROR unknown (or not implemented) command 'm'

Aah, so perhaps xemu doesn't support the 'm' version of the dump command yet, hence why my mdump wrapper returned just zeroes for everything...

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

Paul Gardner-Stephen

unread,

Jan 28, 2018, 10:43:59 PM1/28/18

to Gurce Isikyildiz, MEGA65 Development

Also drop the leading 0, there should be only 7 digits in a 28 bit address, not 8 (which would make it 32 bits)

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

LGB Gábor Lénárt

unread,

Jan 29, 2018, 9:46:29 AM1/29/18

to MEGA65 Development

On Monday, January 29, 2018 at 4:11:05 AM UTC+1, Gurce Isikyildiz wrote:

Oh, good point, didn't notice that earlier...

I tried using the raw serial monitor commands and noticed the following:
<dbg>d0800 (cpu-context dump)
:0000800 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00

<dbg>m0ff80800 (28-bit address)
?SYNTAX ERROR unknown (or not implemented) command 'm'

Aah, so perhaps xemu doesn't support the 'm' version of the dump command yet, hence why my mdump wrapper returned just zeroes for everything...

It's worktime here (the official unfortunately, not M65 related ...) so I've just committed a totally untested implementation into Xemu for this 'm' command. Note: one design feature of Xemu was, that it shouldn't even meet undecoded memory area, and it was even great to check early KS'es etc. But since monitor is hooked via the normal memory decoding of Xemu, it means, if you try to dump something which is an "empty" memory space (no device, memory,i/O space etc there) Xemu will just exit with a fatal error. However, that's easy to cure, just give this command line option to Xemu: -skipunhandledmem

I think shortly I will remove this, and maybe make it reverse :) That is by default it won't cause problems, and if someone really needs this "panic" mode, it can be activated still. But not yet in the code.

Anyway, please test it, hopefully it works at all, it was just a "blind" few lines of code ...

And one other thing: if you ever encounter problems with Xemu's m65dbg interface, you can collect & tell me, sooner or later I should start the "face lifting" project for that too, and every information is kinda useful, what problems I should attack.

Gurce Isikyildiz

unread,

Jan 29, 2018, 2:41:34 PM1/29/18

to LGB Gábor Lénárt, C65GS Development

Thanks man, I will give this a try after work :-)

--

You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

LGB Gábor Lénárt

unread,

Jan 30, 2018, 3:38:38 AM1/30/18

to MEGA65 Development

Oh, and another thing: Xemu by default does not load the "colour RAM utilities" by default. To do that, you need to use the -loadcram CLI switch with the corresponding binary of content for colour RAM. I am not sure, but maybe the utility is in the colour RAM, or at least it needs something from there? Besides the version problem I mentioned, if things are "too new" for Xemu ...

Paul Gardner-Stephen

unread,

Jan 30, 2018, 3:59:35 AM1/30/18

to LGB Gábor Lénárt, MEGA65 Development

Hello,

Yes, the config and FDISK utilities are pre-loaded in the latter part of the colour RAM.

We should probably present an error message when no utilities are found.

Paul.

--

Gurce Isikyildiz

unread,

Jan 30, 2018, 5:58:20 AM1/30/18

to MEGA65 Development

Ok, I've given the new 'm' command in xemu a try. It seems to output something now. I'm just not sure if what it is outputting is right.

Any way to confirm this? As a test, I tried starting a trace somewhere inside kickstart.

It was paused at $AA5C.

So I tried:

<dbg>d aa5c
:000AA5C 38 60 20 52 AA 8D 10 D6 60 20 5E AA B3 10 00 C9

Then I pondered where the equivalent location should be for the m command, and I have to confess, I'm not sure how to work this out.

Does it relate to the MAPH and MAPL values in the registers?

<dbg>r
PC A X Y Z B SP MAPL MAPH LAST-OP P P-FLAGS RGP uS IO
AA5C 00 00 18 00 BF BEFB 0000 0F00 F3 27 00 --E--IZC

So when I check, xemu's monitor tells me MAPH is 0x0F00... So does that mean I can use m to find the data at:

<dbg>m 0f00aa5c
:F00AA5C FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Nup, this differs... With trial and error, I noticed that I got a match if I did it as follows:

<dbg>m 0fffaa5c
:FFFAA5C 38 60 20 52 AA 8D 10 D6 60 20 5E AA B3 10 00 C9

I couldn't fathom why though. Can anyone fill me in with how the 28-bit and 16-bit address map to one another? I had a search around our various knowledge-bases and couldn't find a description of this.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

Gurce Isikyildiz

unread,

Jan 30, 2018, 6:11:33 AM1/30/18

to MEGA65 Development

Another thing I tried was to run xemu with the switches suggested. I tried it as follows:

./build/bin/xmega65.native -skipunhandledmem -loadcram ../mega65-core/bin/COLOURRAM.BIN

The result was a stall prior to any kickstart text appearing:

I haven't debugged this yet (exhausted for tonight), but I'm willing to accept your perspective that my kickstart version is too new.

Just wondering though, is there a particular era of kickstart I should revert back to? A particular version? Or from a particular git commit?

I tried removing my newer KICKUP.M65 and let xemu use its in-built one. This resulted in:

With this version, I don't get any option relating to selecting utilities at all.

So maybe if I pick a kickstart from just the right vintage, xemu will be happy with it and I can see the utils menu?

I'll try debug some more on it tomorrow.

Auto Generated Inline Image 1

Auto Generated Inline Image 2

Paul Gardner-Stephen

unread,

Jan 30, 2018, 6:20:27 AM1/30/18

to Gurce Isikyildiz, MEGA65 Development

Hello,

MAPLO/MAPHI are 16-bit offsets added x 256, so $0F00 means address $0F0000 + 16 bit address. The leading 2 hex digits to make a 28 bit address, i.e., which MB to look in, aren't visible there from memory. The overall address mapping is a bit complex, mostly because of C64/C65 backwards compatibility things.

iomap.txt lists much of the memory map for you, though, and the C65 specifications document covers everything in the $00xxxxx range.

We need to make a more comprehensive memory map, though.

Paul.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

Gurce Isikyildiz

unread,

Jan 30, 2018, 6:40:24 AM1/30/18

to MEGA65 Development

Cheers Paul.

Perhaps I'll need an example just to clarify in my mind.

So in this example, MAPH=00F0, and MAPL=0000

So if the PC is at AA5C, does the maths work out like this?

(MAPH << 8) + MAPL + PC ?

E.g.

MAPH       0F00.. +
MAPL         0000 +
PC           AA5C
--------   ------
ABSOLUTE = 0FAA5C

Gurce Isikyildiz

unread,

Jan 30, 2018, 6:45:11 AM1/30/18

to MEGA65 Development

Oops, pardon my typo, the line should have read:

So in this example, MAPH=0F00 (not 00F0), and MAPL=0000

Paul Gardner-Stephen

unread,

Jan 30, 2018, 6:56:02 AM1/30/18

to Gurce Isikyildiz, MEGA65 Development

Hello,

MAPL is the offset for the lowere 32KB of 16-bit addresses, an MAPH is for the top half. Then there are four bits which indicate which 8KB pieces get the offset, and which don't.

Paul

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

LGB Gábor Lénárt

unread,

Jan 30, 2018, 6:58:50 AM1/30/18

to MEGA65 Development

MAPL refers for the CPU addresses being in the low area (0-7FFF) to be applied while MAPHI is the high (8000-FFFF), so you can't add MAPL+MAPH, they are very different things never applied once, only one. The CPU address decides which. More over, a 8K sized area can be unmapped, when there is no mapping. This is about the C65 stuff, for M65, there is a special case, to select the "megabyte slice", ie which megabyte is selected from the available 256 mbytes.

Gurce Isikyildiz

unread,

Jan 30, 2018, 6:59:34 AM1/30/18

to Paul Gardner-Stephen, MEGA65 Development

Thanks for the details Paul. I'll need to mull this over for a while and let it all sink in.

I guess the pc world brainwashed me with that segment:offset mentality :)

Gurce Isikyildiz

unread,

Jan 30, 2018, 7:00:38 AM1/30/18

to LGB Gábor Lénárt, MEGA65 Development

Cheers LGB :)

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

Paul Gardner-Stephen

unread,

Jan 30, 2018, 7:01:12 AM1/30/18

to Gurce Isikyildiz, MEGA65 Development

Well, it is segment+offset, just that there is a different segment for the top and bottom 32KB, and you can pick which 8KB block has it applied, and the segments are x256, not x16 scaled.

Paul.

LGB Gábor Lénárt

unread,

Jan 30, 2018, 7:05:58 AM1/30/18

to MEGA65 Development

http://cubed-borka.blogspot.hu/2016/10/my-memory-problems-with-commodore-65.html

if it helps. About your Xemu related problems:

First, I've never tried to run the fdisk util inside xemu, I don't know even works. I created my SD image at my own with the FS and the content etc (but actually I found xemu quite useful even for developing M65 software, ie my ethernet test stuff was written on the emulated M65 since meanwhile I also developed the ethernet emulation into Xemu). Actually the "creating empty SD image if cannot be found" feature in Xemu is only few days old.

-loadbanner causes to pre-load the banner image into the memory. KS would do it (I think) as its own too by loading from the SD-card, but then it's only after detecting/mounting SDcard FS of course! So if KS works till a point to set VIC-IV up to display the right memory area, you can see the banner if you use -loadbanner, otherwise only at the time when it can load from the card.

New KS will fail in Xemu currently, because there was an incompatible DMA change, what Xemu does not know about yet. So it can cause freeze/crash whatever since newer KS'es want to do enahcned mode DMA, what Xemu does not even heard yet.

Gurce Isikyildiz

unread,

Jan 30, 2018, 7:09:10 AM1/30/18

to Paul Gardner-Stephen, MEGA65 Development

Fair enough, will read the docs, promise :)

Also, LGB, one thing I noticed while using the serial monitor hooked up to the hardware was that when I did a 'd' command, the result would return with the address given in absolute form:

<dbg>de1a7
:777E1A7 A5 D0 05 D1 F0 FA 20 20 ED 20 77 E1 C9 0D D0 E4

As for xemu, it only displays the 16-bit address you requested.

<dbg>d aa5c
:000AA5C 38 60 20 52 AA 8D 10 D6 60 20 5E AA B3 10 00 C9

Any chance xemu could also return the absolute address too? Just to make it easier for noobs like me ;)

I promise I'm not using this as an excuse not to read the docs, I will read the docs, just not tonight, tired :D

LGB Gábor Lénárt

unread,

Jan 30, 2018, 7:21:00 AM1/30/18

to MEGA65 Development

On Tuesday, January 30, 2018 at 1:09:10 PM UTC+1, Gurce Isikyildiz wrote:

Fair enough, will read the docs, promise :)

Also, LGB, one thing I noticed while using the serial monitor hooked up to the hardware was that when I did a 'd' command, the result would return with the address given in absolute form:

Hmm that is interesting ... Surely it can be modified, maybe I haven't noticed that it is handled differently by the M65 monitor than I thought and I implemented that command badly.

<dbg>de1a7
:777E1A7 A5 D0 05 D1 F0 FA 20 20 ED 20 77 E1 C9 0D D0 E4

As for xemu, it only displays the 16-bit address you requested.

<dbg>d aa5c
:000AA5C 38 60 20 52 AA 8D 10 D6 60 20 5E AA B3 10 00 C9

Any chance xemu could also return the absolute address too? Just to make it easier for noobs like me ;)

No noobs here or there at all. :D I think the rule should be, that it have to be the same as with the "real M65". if there are differences, it's dangerous for even utilities depends on this, like some m65dbg own command features etc ....

So it seems, M65 monitor displays the "absolute" (28 bit wide) address all the time in the hex dump even if CPU-context 16 bit address is requested? I'll check that at home though ...

I promise I'm not using this as an excuse not to read the docs, I will read the docs, just not tonight, tired :D

Never mind, I do the same too, it's sometimes more quick to ask than doing RTFM, so I can't even say a single word here to judge this I am afraid :D :D :D :D

Gurce Isikyildiz

unread,

Feb 3, 2018, 10:59:44 PM2/3/18

to MEGA65 Development

Hiya LGB,

Firstly, a quick note to say your 'm' command addition worked fine for me, and I was able to do an mdump of the colour-ram area and see that the configuration software had been loaded there fine via your -loadcram parameter.

<dbg>mdump ff80800 100
 :FF80800 4D 36 35 55 43 4F 4E 46  49 47 55 52 45 20 4D 45  | M65UCONFIGURE ME
 :FF80810 47 41 36 35 00 00 00 00  00 00 00 00 00 00 00 00  | GA65............
 :FF80820 00 00 00 00 A0 1B 0D 08  00 08 CC 23 01 08 0B 08  | .............
 :FF80830 0A 00 9E 32 30 36 31 00  00 00 4C 64 0D 50 52 4F  | ...2061...Ld.PRO
 :FF80840 50 2E 4D 36 35 55 2E 4E  41 4D 45 3D 43 4F 4E 46  | P.M65U.NAME=CONF

While I was stepping through the kickstart code, I was successfully detected the "M65U" header string, so it seems happy with that.

I know you warned me that I probably will run into trouble using such a new version of kickstart, but I thought I'd brave it anyway, just to see what bits are working, and what bits aren't.

Right now, the odd thing I'm sensing with the new kickup and xemu is that whenever "jsr printmessage" is getting called, I don't see the text appearing in xemu. It just shows the big MEGA65 banner and the rest of the screen remains black.

If I revert to the in-built kickup, such printmessage calls do successfully draw text onto the screen, so maybe I can try see what difference between the kickups caused this difference. Maybe it relates to the DMA changes you were mentioning, or who knows what else... Either way, I'll have a sniff around... :)

Gurce Isikyildiz

unread,

Feb 4, 2018, 6:18:54 AM2/4/18

to MEGA65 Development

Ah wait a sec, I think I see the pattern now.

I've noticed that if I run xemu without the "-loadcram" parameter, I can see the kickstart text:

...but if I run xemu with it, e.g., "-loadcram ../mega65-core/bin/COLOURRAM.BIN" , the text disappears:

It made me wonder if loading up the colour-ram is overwriting or wiping out the character rom/ram in some way?

Gurce

LGB Gábor Lénárt

unread,

Feb 4, 2018, 7:40:16 AM2/4/18

to MEGA65 Development

Hi,

I can't even guess what happen, if you run a newer KS with Xemu. First of all, at the time KS does a DMA, it does in enhanced DMA mode now, what Xemu does not know. Even triggering DMA would not work, since a new register is introduced for that, so what KS thinks that it copied a memory area it won't happened. You can guess what will happen, bad things surely ... The other thing, that if you use a CRAM utility "pack" which may use again the new DMA scheme, or at least something depends on newer KS (so not hw but sw dependency) then again, there is a problem. Now, the problem, that even I haven't got the corresponding CRAM utility "pack" for the KS what Xemu embeds, but to be fair, it must be tried with that (surely, it may not even contains things what it does now). Bit stupid comparison from me (sorry) but it almost feel like you try to run a 386 program on a 286 and guessing what it does without the needed hw (ie, 386 CPU here) support :-) [by the way there as a DOS game looong time ago used only some 386 opcodes in real mode and I used illegal opcode exception to actually emulate those, so I could run the game on my good old 286 eee very slowly - but it's now totally off-topic]. But anyway, it's interesting that you try, and you may found some things, like missing monitor commands during your tries - I say that because I've seen your fork and change in it :-). I still get the hope that I'll time today to finally do the DMA-rewrite in Xemu (but it can turn out, other things changes as well which is needed for newer KS, like SD-card stuffs, buffer moved if I remember exactly and maybe other things, so extensive testing will be needed to say everything is OK, before declaring the new KS'es to be "okey to be use by default" in Xemu.

Gurce Isikyildiz

unread,

Feb 4, 2018, 2:47:20 PM2/4/18

to MEGA65 Development

Hi LGB,

Thanks for your input again. And yes, you're right, the path I chose was an uphill one, so thought I'd better share some perspective on it.

Sometimes it feels like there's so many paths to choose from, that I just pick any path, and see what can be learned from that path, and maybe those experiences can help me pick an easier path in future ;) In the process, I find myself jumping into side-paths and tangents. E.g., I started out looking into an issue for the m65-ide, this led to me feeling frustrated with the limitations of my m65dbg and wanting to improve it. Iterating through debugging tests of new compilations of m65-ide on the hardware got tiring, so xemu felt like a more attractive location to do such debugging. The only gotchya was this new hw/dma stuff. So what to do, maybe try an older generation kickstart and things'll be ok. Maybe stick with the newer kickstart and see what goes wrong with it.

Yeah, I ended up choosing the latter ;) And thanks for accepting the pull request, and no worries if you didn't, I would've understood. The addition of 's' came about late last night where I was just itching for that facility and didn't want to bother you with a request :)

Gurce Isikyildiz

unread,

Feb 5, 2018, 4:45:45 AM2/5/18

to MEGA65 Development

Ok, just as an experiment, I fiddled with the max-size of data that xemu loads in from the COLOURRAM.BIN file, via the line:

    xemu_load_file(p, colour_ram, 0x8000, 0x8000, "Colour RAM content cannot be loaded");

It normally loads all 0x8000 bytes in, but I started decreasing the number:

Loaded only first 0x1000 bytes
- Still no text displayed
Loaded only first 0x500 bytes
- Still no text displayed
Loaded only first 0x400 bytes
- Some portion of text is blanked out, the other portion remains visible

Aah, ok, this has got me thinking that the loading of this colourram data has hidden the text, perhaps by setting the text to the colour black?

I had a look inside COLOURRAM.BIN, and it seems the first 0x0800 bytes are all zeroes.

Here's the result of "hexdump -C COLOURRAM.BIN":

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800  4d 36 35 55 43 4f 4e 46  49 47 55 52 45 20 4d 45  |M65UCONFIGURE ME|
00000810  47 41 36 35 00 00 00 00  00 00 00 00 00 00 00 00  |GA65............|
00000820  00 00 00 00 a0 1b 0d 08  00 08 cc 23 01 08 0b 08  |...........#....|

I'll try take a look how COLOURRAM.BIN gets used elsewhere...

The monitor_load app saves it directly to 0xFF80000.

The auto-generated "colourram.vhdl" rom is made as follows:

tools/makerom/makerom tools/makerom/colourram_template.vhdl COLOURRAM.BIN $(VHDLSRCDIR)/colourram ram8x32k

Taking a look inside, I see it also contains these initial 0x800 chars of 0x00.

So I'm not sure how/why the hardware changes the text colour to white, but xemu doesn't. Aaah, perhaps this is the point where the new DMA got used? To quickly set this portion of colour ram to white somewhere within the kickup?

Is it in the "erasescreen:" section of kickstart.a65 somewhere? I saw 0x0020 16-bit space characters getting written via dma, but I didn't see the point where the colour-ram was set to be white characters. Does it relate to that initial banking in of the 2nd kb of colour ram? I'm not sure what this tsb instruction is, or how dma relates to it here.

erasescreen:
    ; bank in 2nd KB of colour RAM
    ;
    lda #$01
    tsb $D030

Gurce

Paul Gardner-Stephen

unread,

Feb 5, 2018, 5:01:08 AM2/5/18

to Gurce Isikyildiz, MEGA65 Development

Hello,

erasescreendmalist sets it, indeed using new DMA operations. WIthout new DMA, you will have black text.

Paul.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

LGB Gábor Lénárt

unread,

Feb 5, 2018, 7:15:23 AM2/5/18

to MEGA65 Development

One interesting thing: till I have time to really finish the rewrite of the DMA stuff, I tried to "hack" the DMA part of current implementation in Xemu at the possible ugliest way maybe to test what would happen. Interestingly:

DMA: initiation of ENCHANCED MODE DMA!!!!
DMA: list address is $FFFA834 now, just written to register 0 value $34 @ PC=$A7D7
DMA: enhanced option byte $0A read
DMA: enhanced option byte $00 read
DMA: end of enhanced options
DMA: end of operation, but chained!
DMA: enhanced option byte $00 read
DMA: end of enhanced options
DMA: end of operation, but chained!
DMA: enhanced option byte $00 read
DMA: end of enhanced options
DMA: end of operation, no chained next one.
DMA: enhanced-end-of-op, restoring context
DMA: initiation of ENCHANCED MODE DMA!!!!
DMA: list address is $FFFA800 now, just written to register 0 value $00 @ PC=$A7DC
DMA: enhanced option byte $C8 read
DMA: *unknown* enhanced option: $C8
DMA: enhanced option byte $C8 read
[...etc...]

So, it seems a kinda "usable" DMA transfer is done, then totally garbage, even enhanced mode option list contains unknown options. However the interesting part, that I tried to use kickstart.list to tell, what it is, why the KS puts zero for the lowest address (NOTE: the debug messages above SEEMS TO BE wrong to mention "register 0" when it's register 5 in case of enhanced mode DMA. It's not a bug, just the hack how I implemented it at this stage - it was reg 5, otherwise no "initiation" msg would be done before by Xemu).

However kickstart.list contains this:

9FA6 09 30     ORA   #$30         | kickstart.a65:2762
9FA8 C9 3A     CMP   #$3A         | kickstart.a65:2763
9FAA B0 01     BCS   $00AD          | kickstart.a65:2764
9FAC 60        RTS                  | kickstart.a65:2765
9FAD 69 06     ADC   #$06         | kickstart.a65:2766
9FAF 60        RTS                  | kickstart.a65:2767
9FB0 43 68 65 63 6B 70 6F 69 6E 74 20 40 20 24 25 25 |Checkpoint @ $%%|
9FC0 25 25 20 41 3A 24 25 25 2C 20 58 3A 24 25 25 2C |%% A:$%%, X:$%%,|
9FD0 20 59 3A 24 25 25 2C 20 5A 3A 24 25 25 2C 20 50 | Y:$%%, Z:$%%, P|
9FE0 3A 24 25 25 20 3A 20 20 20 20 20 20 20 20 20 20 |:$%% :          |
9FF0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |                |
A000 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0D 0A |              ..|
A010 52 45 2D 54 52 59 49 4E 47 20 54 4F 20 52 45 41 |RE-TRYING TO REA|

And from this point, only binary dump, nothing more. :-O

LGB Gábor Lénárt

unread,

Feb 5, 2018, 7:18:03 AM2/5/18

to MEGA65 Development

OK sorry forget the kickstart.list stuff! it seems there are two kickstart.list files now in my source tree, some is one year old and in other directory. Sorry about the confusion.

LGB Gábor Lénárt

unread,

Feb 5, 2018, 7:58:27 AM2/5/18

to MEGA65 Development

Btw, it's this code fragment:

A7D2 A9 34     LDA   #$34         | src/kickstart.a65:1776
A7D4 8D 05 D7 STA   $D705          | src/kickstart.a65:1777
A7D7 A9 00     LDA   #$00         | src/kickstart.a65:1781
A7D9 8D 05 D7 STA   $D705          | src/kickstart.a65:1782
A7DC A9 01     LDA   #$01         | src/kickstart.a65:1786

(Xemu reports PC after incrementing PC, btw)

Now in the source:

                ; clear source/destination MB so that C65 ROM doesn't go bananas
                ;
                lda #$00
                sta $d705

Uh. It seems to be kinda stange for me, register d705 is not for setting MB, at least not with new enhanced mode dma scheme ...

Can it be actually a bug in KS, that an old and now not needed old-DMA-related stuff remained in the source? For me it seems to be, since with new DMA, D705 triggers an enhanced mode DMA!

Hmm, I am curious now to grep KS's source to find DMA register writes if there are similar things left in it.

Paul Gardner-Stephen

unread,

Feb 5, 2018, 8:15:52 AM2/5/18

to LGB Gábor Lénárt, MEGA65 Development

Hello,

Yes, that shouldn't be there.

Paul.

--

You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

Paul Gardner-Stephen

unread,

Feb 5, 2018, 8:17:40 AM2/5/18

to LGB Gábor Lénárt, MEGA65 Development

... patched and pushed to github.

Paul.

LGB Gábor Lénárt

unread,

Feb 5, 2018, 8:25:29 AM2/5/18

to MEGA65 Development

WOw, thanks. You're fast. Much faster than me coding things actually ... :-O :) :)

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

LGB Gábor Lénárt

unread,

Feb 5, 2018, 9:00:23 PM2/5/18

to MEGA65 Development

I spent a little time for now to hack Xemu for new KS in an ugly way. Now I can even go into the settings utility, etc. SD-card util and sd-boot does not work since KS wants to do something at address $FFD6000 which is interesting because:

      -- Also map SD card sector buffer at $FFD6000 - $FFD61FF regardless of
      -- VIC-IV IO mode and mapping of colour RAM
      -- @ IO:GS $FFD6E00-FFF - SD card direct access sector buffer
      -- @ IO:GS $FFD6C00-DFF - F011 floppy controller sector buffer

So yes, $FFD6000 but actually only some of its sub-areas are mentioned that used for something, not below 6E00. But anyway, I remember we had some words on this in a mail ...

The other even more interesting (if I can say that) thing that a some day old KS/colour-RAM combo worked for me at least to enter settings utility. However the "brand new" does not, it simply does not sense that I pressed '1' to configure mega65. Maybe there was some change in the kbd handling (Xemu has some support for the D610 port, but only that and the modifier byte, and I saw now lots of DEBUG-marked stuff in this topic in iomap.txt).

Paul Gardner-Stephen

unread,

Feb 5, 2018, 9:25:48 PM2/5/18

to LGB Gábor Lénárt, MEGA65 Development

Hello,

Yes, the $D610 interface has some nasty bugs on the real hardware at the moment. But it does work with kickstart on hardware, so it should be possible to make it work on Xemu at the moment as well. It might be that writing to $D610 is not being handled correctly to pop characters off the queue.

Paul.

--

You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

LGB Gábor Lénárt

unread,

Feb 6, 2018, 3:19:42 AM2/6/18

to MEGA65 Development

Hmm, interesting, if I disable the "trigger next key" stuff in Xemu it works, so somehow KS always removes the key event then it won't see again. Maybe the hw does not do the same, but if someone writes D610, I return with zeto by reading D610 again since there is no "new" key pressed, and the one was already "deleted", or how I can tell. But what is interesting for me, that it worked (with Xemu too I mean) with only some days ago's KS which use the very same kickstart_keyboard.a65 it hasn't changed. Maybe there is some new behaviour what it depends on, ie it can still re-read the value after triggering the "next event" with D610? Honestly, the support in Xemu does not use FIFO yet, just a very simple approach with a single variable, ie if I press a key, I store the ASCII value in it. By reading D610 it always read that variable. It only changes to zero, if D610 is written. Well, maybe it's not the very same what M65 does, and it's not even a FIFO (ok, maybe a 1-deep FIFO ehmmm), but what is interesting it worked only some day ago.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

Gurce Isikyildiz

unread,

Feb 16, 2018, 1:16:37 AM2/16/18

to MEGA65 Development

Hi guys,

I've been pushing along trying to get the latest kickstart working with the latest xemu, so that I can press on with debugging m65-ide.

Just wanted to share some of my observations along the way. Sorry for the long-windedness.

I've used -newhack argument to my xemu call, to get the new DMA implementation Gabor implemented. That got me to the kickstart screen successfully, awesome:

But if I choose option 2, I get this:

If I choose option 1 though, looks good:

If I then press F10 in xemu (for a soft restart) and then select option 2, it then displays correctly:

I did the "DELETE EVERYTHING" command. I was applying this to a raw/fresh mega65.img file that xemu had offered to autogenerate, so I wasn't worried about losing anything.

However, upon completion, the sd-card is still un-usable. After having a look at the mega65.img file via hexdump, all bytes are still zero, so nothing was written to them.

Ah well, perhaps this could relate to the new dma implementation, so I didn't push much further in that direction.

I instead tried using Gabor's pre-prepared image from online. I'll share how that went.

wget https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/sd-card-image-for-xemu-xmega65.img.gz
gunzip -k sd-card-image-for-xemu-xmega65.img.gz
mv sd-card-image-for-xemu-xmega65.img "~/.local/share/xemu-lgb/mega65/mega65.img"

But when I use this image and re-run xemu, it still offers the utility menu:

This surprised me somewhat, as I thought that this utility menu should only appear when the alt key is down. After looking at the .a65 source, I learnt it also appears when no disks are found on the sdcard image.

Aah, so that's why the disk-count in the kickstart bootup was showing as zero:

I mounted the mega65.img locally and confirmed it definitely had content on it, and a .D81 file. So then it became a question of why it wasn't being located.

I did some debugging around the readmbr: section of the assembly and confirmed it retrieved the MBR from sector 0 successfully, and it matches what I see in the mega65.img file via dd and hexdump:

dd if=mega65.img bs=1 count=512 2> /dev/null | hexdump -C -v | less

This seems to be the part of interest with the partition info for the 1st partition:

000001b0  00 00 00 00 00 00 00 00  59 88 07 d9 00 00 00 00  |........Y.......|
000001c0  01 20 0c 03 d0 ff 00 08  00 00 00 a0 0f 00 00 00  |. ..............|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

Ok, time to interpret what that all means:

00 00 01 20 0c 03 d0 ff 00 08 00 00 00 a0 0f 00
0c = partition type = FAT32 with LBA (not CHS)
- Aah, since we're using LBA, the CHS fields of this partition entry can be ignored, I think...
00 08 00 00 = LBA of first sector in partition
= 0x00000800
= sector 2048
= 2048 x 512 = 1048576 'th byte
00 a0 0f 00 = Number of sectors in partition
= 0x000fa000
= 1024000 sectors
= 524288000 bytes
= 500 MB

Aah right, so if I do a dd of this 1048576 offset, I can see the boot-sector (VBR) of this 1st partition:

dd if=mega65.img bs=1 count=512 skip=1048576 2> /dev/null | hexdump -C -v | less

00000000  eb 58 90 6d 6b 66 73 2e  66 61 74 00 02 08 38 02  |.X.mkfs.fat...8.|
00000010  02 00 00 00 00 f8 00 00  10 00 04 00 81 00 00 00  |................|
00000020  00 a0 0f 00 e6 03 00 00  00 00 00 00 02 00 00 00  |................|
00000030  01 00 06 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  80 01 29 43 f0 a3 56 4c  4f 55 44 20 20 20 20 20  |..)C..VLOUD     |
00000050  20 20 46 41 54 33 32 20  20 20 0e 1f be 77 7c ac  |  FAT32   ...w|.|
00000060  22 c0 74 0b 56 b4 0e bb  07 00 cd 10 5e eb f0 32  |".t.V.......^..2|
00000070  e4 cd 16 cd 19 eb fe 54  68 69 73 20 69 73 20 6e  |.......This is n|
00000080  6f 74 20 61 20 62 6f 6f  74 61 62 6c 65 20 64 69  |ot a bootable di|
00000090  73 6b 2e 20 20 50 6c 65  61 73 65 20 69 6e 73 65  |sk.  Please inse|
000000a0  72 74 20 61 20 62 6f 6f  74 61 62 6c 65 20 66 6c  |rt a bootable fl|
000000b0  6f 70 70 79 20 61 6e 64  0d 0a 70 72 65 73 73 20  |oppy and..press |
000000c0  61 6e 79 20 6b 65 79 20  74 6f 20 74 72 79 20 61  |any key to try a|
000000d0  67 61 69 6e 20 2e 2e 2e  20 0d 0a 00 00 00 00 00  |gain ... .......|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

So the partition information in the image is legit...

I step through the code around dos_read_partitiontable: and kickstart_dos.a65:728:
; Partitions start at offsets $1BE, $1CE, $1DE, $1EE
; so consider each in turn. Opening the partition causes other sectors to
; be read, so we must re-read the MBR between each

; get pointer to second half of sector buffer so that we can access the
; partition entries as we see fit.
;

lda #<[sd_sectorbuffer+$1BE]
sta dos_scratch_vector
lda #>[sd_sectorbuffer+$1BE]
sta dos_scratch_vector+1
I then see it prepare to read the boot-sector of the first partition, by preparing sd_address_byte0-4 to equate to the sector to read:

#4: DWORD sd_address_byte0: 00000800
...and then calling sd_readsector:
...after this, there is a call to sd_map_sectorbuffer: which I think will drop the sd-sector's contents into sd_sectorbuffer (0xDE00 - 0xDFFF) region of memory.
When it was called previouslky for reading of the MBR, the contents of sd_sectorbuffer were correct.
But after trying to read the 1st sector of the 1st partition, all I get is zeros, that's not right...

:000DE00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEA0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DED0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFA0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

I then took a look inside xemu's "targets/mega65/sdcard.c" to learn how this sdcard reading was done.

I saw sdcard_command() had case 0x02: for reading a block
This called diskimage_read_block() to do this task, feeding it an offset via the sd_sector_bytes parameter (which equated to the correct 0x00000800 offset requested).
Within diskimage_read_block() was a call to host_seek_to() which I then found a point of concern:

if (lseek(fd, image_offset, SEEK_SET) != image_offset)
This image_offset value equated to 0x00000800 (passed in via sd_sector_bytes), which is the correct offset, but in units of sectors. The lseek() function is seeking in units of bytes.
So, to test my theory, I tried editing this line to become:

if (lseek(fd, image_offset*512, SEEK_SET) != image_offset*512)
I ran xemu again, and hey presto! The c65 startup screen is back! No more utility menu! :)

I tried GO64, and load up that default MEGA65.D81 disk image, but the LOAD "$",8 for it just returns:

I'll save that debugging journey of the .D81 file for another time.

Auto Generated Inline Image 1

Auto Generated Inline Image 2

Auto Generated Inline Image 3

Gurce Isikyildiz

unread,

Feb 16, 2018, 4:13:11 AM2/16/18

to Paul Gardner-Stephen, C65GS Development

Thanks Paul :) I'll cc your response back into the forums so it's on Gabor's radar too.

I'll try plug away at the prob with reading the .D81 image next. With that resolved, hopefully m65-ide will work through xemu once more, and should speed up the debugging/development of it.

On 16 February 2018 at 17:48, Paul Gardner-Stephen <pa...@servalproject.org> wrote:

The underlying problem is that kickstart now recognises SDHC cards that use offsets in sectors, not in bytes.
Kickstart thought the card was an SDHC one, not a regular SD one. Xemu needs to handle this, and seek accordingly depending on the card mode.

Paul.

--

You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

Paul Gardner-Stephen

unread,

Feb 16, 2018, 11:40:43 AM2/16/18

to Gurce Isikyildiz, C65GS Development

Hello,

all sounds good.

Paul.

Gurce Isikyildiz

unread,

Feb 16, 2018, 7:31:41 PM2/16/18

to MEGA65 Development

Okidokey, I tinkered with xemu a bit more, to let it convince kickstart it was an SD card (and not an SDHC). As the tinker involved editing a few places here and there, I thought it'd be better to summarise it in a git commit to my forked repo:

https://github.com/gurcei/xemu/commit/de0e5725d36cfdaabd08b76b22edd74a8794ade8

I thought I'd better not do a pull request back to Gabor's repo for this, as my effort is also just a quick hack, and probably he'll eventually want to support both SD and SDHC images, and report the proper status back to kickstart accordingly.

Still, I'm happy I can now boot into c65 mode, jump to c64 mode and dir a d81 disk :)

I also tried using the m65-fdisk utility to see if it could prepare a fresh sdcard image made by xemu, but it just seemed to stall at this point:

I thought about debugging it, but it's written in C (for cc65), so I'll put it in the "too-hard" basket for now, until I try get m65dbg to support .list and .map files generated from cc65. Which I slowly feel an itch for anyway, as the m65-ide is also written in C, so would be a handy way to debug it too! :)

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

LGB Gábor Lénárt

unread,

Feb 16, 2018, 11:24:07 PM2/16/18

to MEGA65 Development

Hi,

On Friday, February 16, 2018 at 7:16:37 AM UTC+1, Gurce Isikyildiz wrote:

I've been pushing along trying to get the latest kickstart working with the latest xemu, so that I can press on with debugging m65-ide.

Just wanted to share some of my observations along the way. Sorry for the long-windedness.

I've used -newhack argument to my xemu call, to get the new DMA implementation Gabor implemented. That got me to the kickstart screen successfully, awesome:

It's really a dirty hack ... Since it seems the "sane" DMA rewriting from me is longer than I expected (not because the size of the work, but also other things to do, etc etc). But it's great if works for some degree at least in this way too. Surely, I also tested with new KS, and what I found, that I have issue with the hardware accelerated ASCII keyboard thinggy, so I can't even do too much, when it waited for keypress to utility etc, it simply does not work. If I remove the "empty FIFO" policy, it works, just then the keypress stuck forever, well, not so surprisingly. What I think here (but I can be wrong!!!) that M65 has some issues (as Paul mentioned too) with that too. And maybe I don't emulate the "issues", or at least not the really same ones ;-P

If I then press F10 in xemu (for a soft restart) and then select option 2, it then displays correctly:

Interesting. I got the same as you with the "garbage". But it's surprising you tried F10, honestly I haven't even had the idea to try that, you're really a great tester talent as well, it seems :) I've also tested settings with Xemu btw.

...after this, there is a call to sd_map_sectorbuffer: which I think will drop the sd-sector's contents into sd_sectorbuffer (0xDE00 - 0xDFFF) region of memory.

Be careful with this one. For multiple reasons. As far as I remember now by heart, indeed SD card sector buffer can be mapped to the I/O area if you wish. But it you do so, it's an I/O area, not a real memory address, I am not sure what you've tried to hexdump. And even if you try to dump the I/O area and *not* memory address $DE00 then you can only see it, if sector buffer is mapped to the I/O space, you can set that on/off, as you may need the I/O expansion areas, what it overlays otherwise.

Moreover, SD sector buffer is also mapped without the I/O complexity thingy to ask to map etc. From $FFD6000 (but see memory_mapper.c) there is a 4K area what is (if I am right ....) with also holds SD sector buffer and F011 sector buffer (at the end of this 4K space). Paul even had a blog post on this, what he didn't want this mapping the I/O buffer to the I/O space thingy everywhere to push at any price everywhere with the only solution to access the sector buffer (if I remember correctly). No connected with the -newhack option though, but this is already emulated in Xemu (regardless of the -newhack switch is used or not, I guess older KS didn't expected that feature at all - so no problem with this). However Xemu lacks for example the I/O area mapping of F011 sector buffer (maybe it's also a problem for newer KS somewhere?), always only SD card sector buffer would work.

But after trying to read the 1st sector of the 1st partition, all I get is zeros, that's not right...

:000DE00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

OK, now I should know what kind of dump is this. As I mentioned, if it's simply memory address $DE00 it won't work, no wonder, since then it's memory address $DE00 and not I/O address space. And even if it is I/O space what you dumped, it works only, if you set mapping sector buffer area to I/O space bit.

This image_offset value equated to 0x00000800 (passed in via sd_sector_bytes), which is the correct offset, but in units of sectors. The lseek() function is seeking in units of bytes.

No. SD card in non-SDHC mode works with units of bytes actually. SDHC cards at the other hand really works with units of sectors. Xemu emulates only non-SDHC cards. And anyway if it is wrong in Xemu nothing would work, because everything would be way out of the normal place, right starting from the very first Xemu/mega65 version :) But surely, it CAN be a bug, that KS tests if SDHC card is used, and it mis-interprets if it is, but for real Xemu emulates non-SDHC.

So, to test my theory, I tried editing this line to become:

if (lseek(fd, image_offset*512, SEEK_SET) != image_offset*512)

Don't do that. Xemu basically emulates non-SDHC card (so <2Gbyte), where addressing is BYTE based (that's the reason it's not multiplied with 512 by default, as byte addressing is used there!). For something like you tried, it must be in SDHC mode then. Actually you may try that too btw, I *guess* (I am not sure) that KS can figure out if the card is SDHC or not. Just it probably won't work with Xemu, since - as far as I remember - it does by try trying to use non 512-byte alignment read to test if addressing in block mode (SDHC) or byte mode (non-SDHC) can be done. However, honestly I am not the master of the topic, I can say ... I felt with Xemu, that probably 2Gbyte is enough for the emulator, so I didn't even tried SDHC. But surely, maybe it's not a bad thing to provide that too, not only because of the max allowed size, but also to test software with Xemu with both of SDHC and non-SDHC scenarios.

Well, to say better: don't put that multiplication there UNLESS you want to emulate SDHC card. But Xemu does not support SDHC addressing currently, or at least maybe it lack the feature that KS can test well enough if the card is SDHC or not, because it's the condition that it must do byte or sector unit addressing. I didn't include the multiplication for the sole purpose that SDHC is currently not supported at all.

LGB Gábor Lénárt

unread,

Feb 16, 2018, 11:28:06 PM2/16/18

to MEGA65 Development

On Saturday, February 17, 2018 at 1:31:41 AM UTC+1, Gurce Isikyildiz wrote:

Okidokey, I tinkered with xemu a bit more, to let it convince kickstart it was an SD card (and not an SDHC). As the tinker involved editing a few places here and there, I thought it'd be better to summarise it in a git commit to my forked repo:

https://github.com/gurcei/xemu/commit/de0e5725d36cfdaabd08b76b22edd74a8794ade8

Sorry, I just read this now (and Paul's answer) _AFTER_ post my response to your message, but as far as I can see basically the problem is about the issue I've also written, that Xemu only supports non-SDHC, and probably KS fails to test properly if this is SDHC or not, because I don't check misaligned reads what KS would use to test with. So it seems it turns out it's really the case. Thanks for the testing, I'll have a look on this!

LGB Gábor Lénárt

unread,

Feb 16, 2018, 11:30:43 PM2/16/18

to MEGA65 Development

And with "KS fails to test properly" I meant that fails to test properly because of missing Xemu feature ;-P

LGB Gábor Lénárt

unread,

Feb 16, 2018, 11:53:38 PM2/16/18

to MEGA65 Development

Hi,

First of all, thanks for your efforts and the nice work :)

On Saturday, February 17, 2018 at 1:31:41 AM UTC+1, Gurce Isikyildiz wrote:

Okidokey, I tinkered with xemu a bit more, to let it convince kickstart it was an SD card (and not an SDHC). As the tinker involved editing a few places here and there, I thought it'd be better to summarise it in a git commit to my forked repo:

https://github.com/gurcei/xemu/commit/de0e5725d36cfdaabd08b76b22edd74a8794ade8

I thought I'd better not do a pull request back to Gabor's repo for this, as my effort is also just a quick hack, and probably he'll eventually want to support both SD and SDHC images, and report the proper status back to kickstart accordingly.

Never say never - I only told that Xemu didn't supported SDHC mode at all :) However my main issue here (about everything to develop in relation of SD-card emulation), that even I just do guessing how it should work ... For example, some points:

* what does actually SDHC mode does if set or not set? is it enough to behave according to that for sector/byte addressing selection? what does being done differently on a real M65, because if I understand correctly, you can set SDHC mode for non-SDHC card as well and vice versa, just it makes no sense of course. So I am really not sure the very well defined behaviour what it does exactly.
* from this commit, I see, BUSY flags are set if non-aligned access done. Why? Or is this really what M65 does? This is another weak point I can't fully understand (and while emulating something, it never hurts if you do ...) there are two ERROR bits and too BUSY bits .. I really would like to collect enough information to see, actually very detailed basis what command in what situation causes what status bits set/reset for every cases ...
* if you see sdcard_read_register() function ... As far as I can remember $D688/9 registers meant once that how many bytes read ... I didn't understand that too much eg, logically zero or 512 and not between, but it's possible to read a piece of the sector, or what it wanted to mean this information? More over, currently according to the iomap.txt these registers does not even mean this any more ...

I would be extremely happy, if there is some information about these topics, detailed enough that Xemu can be done better to follow what M65 actually does. And maybe that information is useful for others too as some kind of part of the "universal M65 documentation Bible" :-) I mean about "SD controller documentation" or kind of :)

Gurce Isikyildiz

unread,

Feb 17, 2018, 1:09:45 AM2/17/18

to MEGA65 Development

Hiya Gabor,

> First of all, thanks for your efforts and the nice work :)

No probs, I enjoyed the adventure :) And thanks for the compliment on my testing discoveries! :D I appreciate the detail you've gone to in your responses, just sadly my speed of comprehension can be a bit slow, and I tend to need to re-read things multiple times before the penny drops :) I'll try cover the bits I can respond to immediately though below.

> Surely, I also tested with new KS, and what I found, that I have issue with the hardware accelerated ASCII keyboard thinggy, so I can't even do too much, when it waited for keypress to utility etc, it simply does not work. If I remove the "empty FIFO" policy, it works, just then the keypress stuck forever, well, not so surprisingly. What I think here (but I can be wrong!!!) that M65 has some issues (as Paul mentioned too) with that too. And maybe I don't emulate the "issues", or at least not the really same ones ;-P

Yes, agreed, I've also witnessed some problems with keypresses that aren't registering properly within the kickstart menu. I think I also noticed that if I press the TAB key during kickstart, it gets upset with me, with this message:

I haven't looked into that as yet. Sometimes it takes me by surprise when I alt-tab between the app and another window (with the tab key in the alt-tab triggering this crash :)), so just thought I'd give some heads-up on this observation too.

if (lseek(fd, image_offset*512, SEEK_SET) != image_offset*512)

> Don't do that. Xemu basically emulates non-SDHC card (so <2Gbyte), where addressing is BYTE based (that's the reason it's not multiplied with 512 by default, as byte addressing is used there!).

Hehe, yup, the *512 was a silly thing I tried initially, not knowing any better. Ah well, the silly way taught me some lessons and evolved my understanding on the matter. The improved technique I did in the fork commit avoids doing this multiplication and instead tries to convince kickstart that it is an SD-card rather than an SDHC card, hence keeps the lseek() in units of bytes.

You also had some Q's on the SD vs SDHC behaviour. Sadly, I have limited knowledge on this topic, so all I based my efforts on were faking the flags to be whatever was needed to convince kickstart it was an SD (and not SDHC).

I tracked down the test that decides whether this is an SD or SDHC card to within "kickstart_sdfat.a65".

There's a request to read sd_address 0x0000002, intentionally chosen to not be on 512-byte boundary. So it seems that this is something that is being used to make that decision, an SD-card can't do this, but an SDHC-card can:

    ; Work out if SD card or SDHC card
    ; SD cards only read on 512 byte aligned addresses.
    ; SDHC addresses by sector, so all addresses are valid
    ; Attempt non-aligned read
    lda #$02
    sta sd_address_byte0
    sta $d680
sdhccheckwait:
    jsr sdreadytest
    bcs issdhc
    bne sdhccheckwait

Then inside this jsr to sdreadytest:, I noticed that it's assessing if bits 0 and 1 of the $D680 status are on (which I saw in xemu's code equated to SD_ST_BUSY1 and SD_ST_BUSY2):

> mega65-core/src/kickstart_sdfat.a65:188
> 178:          rts
> 179:
> 180: ;        ========================
> 181:
> 182: sdreadytest:     ; check if SD card is ready, or if timeout has occurred
> 183:          ; C is set if ready.
> 184:          ; Z is set if timeout has occurred.
> 185:          ;
> 186:          lda $d680
> 187:          and #$03
> 188:          beq sdisready
> 189:          inc sdcounter+0
> 190:          bne sr1
> 191:          inc sdcounter+1
> 192:          bne sr1
> 193:          inc sdcounter+2
> 194:          bne sr1

So the test is for a request of sd_address = 0x00000002, which is not aligned to a 512-byte boundary.

So if this stalls with busy flags for too long, then we confirm it's just an SD card
If it works instantly, we've confirmed it's an SDHC card
Since xemu presently is only familiar with SD-cards, my quick workaround fix in the commit was to force this LDA $D680 to always return busy flags if a non 512-byte boundary address was requested. It will only return a non-busy value if a 512-byte boundary address is requested.

Honestly, I do this with zero personal understanding of the difference between SD and SDHC cards, I was just going off what I saw kickstart was expecting for its test ;)

Auto Generated Inline Image 1

LGB Gábor Lénárt

unread,

Feb 17, 2018, 12:38:10 PM2/17/18

to MEGA65 Development

Ahoy Gurce,

On Saturday, February 17, 2018 at 7:09:45 AM UTC+1, Gurce Isikyildiz wrote:

Hiya Gabor,

> First of all, thanks for your efforts and the nice work :)

No probs, I enjoyed the adventure :) And thanks for the compliment on my testing discoveries! :D I appreciate the detail you've gone to in your responses, just sadly my speed of comprehension can be a bit slow, and I tend to need to re-read things multiple times before the penny drops :) I'll try cover the bits I can respond to immediately though below.

Honestly, at many points in Xemu I just did a "try & error" approach to emulate M65, I just tried many things till it seems to work at least to be able to "boot". However this is not the best method, as maybe some other software then won't run with Xemu doing things a bit differently than the given KS version for example. That's why I wrote, that there should be a detailed documentation how exactly SD controller behaves, even with all the quirks of it on M65, I must emulate the same, as I don't want to invent a new machine but I want to emulate M65 as it is, as close as possible, at least that would be the goal, which is quite far sometimes, indeed (and since M65 also changes in time, I need to follow that also). About the M65 "quirks" I want to mention, that according to the VHDL reset then end-reset command sequence should clear error bits. Now I've tried that on the *real thing* and I was surprised to see, it's not the case ... But surely it's only one thing. I don't say that this is "bad" how M65 works, just that it's bad Xemu does not do the very same, leading incompatibilities with the machine wants to emulate. I have a project now "eth-tool" which is a network capable "server part" for a client running on Linux, so you can interact with M65 through the network (now I have even client side FAT32 handling and raw level SD card access through the network - in the form of IP/UDP protocol -, but no write yet ...). Currently for example I cannot figure out how I can write an SD sector, for some reason it's simply does not for for me with real M65, even after trying to understand what fdisk-mega65 does exactly to be able to write a sector.

And for sure, this -newhack option will go away. Just currently I want to retain the old Xemu behaviour with its built-in KS because it seems to work at least which cannot be said about the newer things :) At the point when we have newer KS works without major issue etc, this will be the default of course, and also Xemu's built-in KS will be upgraded etc etc to that point.So basically -newhack is for testing to see if we're there yet. Not exactly but getting closer hopefully :)

Another consideration: currently, Xemu has a built-in KS, but eg not the colour RAM utilities. It must be loaded with -loadcram option. Surely it can have a default value but then still, user needs to download that first. I'm thinking to include "some" utilities matches the internal KS also included by default in Xemu binary I mean. This is currently the situation with "default" KS, btw. However it's a bit unfortunate that you must upgrade Xemu binary then (or use the options to force load other). I wouldn't think it's a problem to include "binary from other sources" inside Xemu, as these materials (KS, etc) from mega65-core which is also GNU/GPL and source is available. Surely, including mega65.rom for example would be a bigger problem on the legal side ...

> Surely, I also tested with new KS, and what I found, that I have issue with the hardware accelerated ASCII keyboard thinggy, so I can't even do too much, when it waited for keypress to utility etc, it simply does not work. If I remove the "empty FIFO" policy, it works, just then the keypress stuck forever, well, not so surprisingly. What I think here (but I can be wrong!!!) that M65 has some issues (as Paul mentioned too) with that too. And maybe I don't emulate the "issues", or at least not the really same ones ;-P

Yes, agreed, I've also witnessed some problems with keypresses that aren't registering properly within the kickstart menu. I think I also noticed that if I press the TAB key during kickstart, it gets upset with me, with this message:

I haven't looked into that as yet. Sometimes it takes me by surprise when I alt-tab between the app and another window (with the tab key in the alt-tab triggering this crash :)), so just thought I'd give some heads-up on this observation too.

Hmmm :) I am not sure about this, but AFAIK there is some task switching stuff in M65 or like that with ALT-TAB. And surely you only want to use ALT-TAB on your PC, but Xemu gets the keypress before your OS reacts to switch windows, so it also behaves according to that. It's an interesting question how it can be handled nicely in an emulator. I mean it's hard to distinguish in Xemu between keypresses "not intended" for it, or for things intended for it. Maybe ALT-TAB and some "critical" key combos should be filtered out, unless Xemu is run in full-screen mode, or whatever ... About the crash, it's just a check enforced, that in hypervisor mode, no code can be run outside of the hypervisor memory. It's also possible that it's normal that KS wants this, just it's against the old rule that it should not happen, and what was a request for Xemu that it should check this, to help KS development "in the old days". Surely again, this whole M65 freeze/task switching/etc stuff is something, I don't know too much about :( Currently ... :-D Anyway maybe TAB does not even for this function? I can't remember now :(

But btw, you can try to find that error msg in the source and comment it out not to allow to force this check, but maybe it will cause even bigger problems later :-O

if (lseek(fd, image_offset*512, SEEK_SET) != image_offset*512)
> Don't do that. Xemu basically emulates non-SDHC card (so <2Gbyte), where addressing is BYTE based (that's the reason it's not multiplied with 512 by default, as byte addressing is used there!).

Hehe, yup, the *512 was a silly thing I tried initially, not knowing any better. Ah well, the silly way taught me some lessons and evolved my understanding on the matter. The improved technique I did in the fork commit avoids doing this multiplication and instead tries to convince kickstart that it is an SD-card rather than an SDHC card, hence keeps the lseek() in units of bytes.

Do not blame yourself. I did exactly this when I first tried SD-card thing to put into Xemu :D So it was also a try&error method from me, since I was not sure how it works on M65 ...

Maybe I am wrong here, but I am actually thinking that Xemu would be able to work both of SDHC and non-SDHC mode for any SD image size, just controlling the unit being byte or sector according to the SDHC flag set in the status (which can be set with commands). In the "real world" a card is either SDHC or not, but maybe I can emulate both with any image size, though it's just strange that SDHC cards are usually (?) bigger than 2Gbyte) [4?] at least, but who said that an SDHC card method wouldn't work in theory with extra small cards as well? But I am not sure, maybe it would cause just problems, that M65 software (including KS) would expect either SDHC or non-SHDC works but not both :-O Even if it's possible to do in Xemu run-time, but it's not the case for the real hw. Anyway, maybe based on image size will be the right thing to choose what should be close to the "real world" as well, I think (or use command line option to force one).

Interesting :-O I would think otherwise, that trying non-aligned access would result in ERROR. But then it seems it just result in being busy for a loooong time, so the wait loop would timed out? :-O That's also an interesting question since Xemu basically does not emulate busy flag too much. It "cheats" that it's always ready, every commands are served with result instantly. Surely it can be "emulated" to be "slower" but it would require check elapsed time/cycles/whatever and would cause other complexities as well. But anyway, for a quick hack what you tried seems to be OK. But the best would be - of course - to know exactly every status bit change etc for every ops for every conditions to have a nice matrix to see how it behaves. It would also help M65 software development not just Xemu.

Gurce Isikyildiz

unread,

Feb 17, 2018, 9:35:12 PM2/17/18

to MEGA65 Development

Hiya Gabor,

Yep, I hear you on wanting to follows what/how the hardware behaves exactly (and documenting it), that'd be the ideal. Still, I accept that reaching ideals takes time and effort, so I'm content to get by with workarounds and approximations until we get to that ideal :)

Your eth-tool sounds exciting, particularly the idea of accessing the sd-card remotely for read and write, I'm looking forward to giving that one a try :)

Agreeing with you on the -newhack param being a temporary/interim thing, and the possibility of a default colourram content being provided one day.

Thanks for the insights and reasoning for my ALT-TAB woes too, I forgot about the m65's own ALT-TAB mechanism.

Gurce

Gurce Isikyildiz

unread,

Feb 17, 2018, 10:35:31 PM2/17/18

to MEGA65 Development

Hiya Gabor,

I did have a few extra q's on xemu's parameters. I did have a read of the wiki-page you suggested first:

https://github.com/lgblgblgb/xemu/wiki/targets-mega65

This line took my interest:

You may want to place kickstart.list file into rom/ as well, so Xemu can use it for hypervisor debugging

I wanted to better grasp of how this was done and how it will benefit me. I'm trying to look at the source to garner some of this understanding too, so I think it means I need to call xmega65.native with these parameters:

./build/bin/xmega65.native -kickuplist ../mega65-core/kickstart.list -hyperdebug

But I didn't quite understand what I would get in return for adding these parameters?

Does it relate to logging section, and the XEMU_DEBUG_FILE environment variable? I.e., if I set this env-var, along with -kickuplist and -hyperdebug, I'll get some extra goodies handy for debugging?

Gurce Isikyildiz

unread,

Feb 17, 2018, 10:55:54 PM2/17/18

to MEGA65 Development

Having a tinker with it now, and think I got an understanding now, by the following two runs, with the addition also of this XEMU_DEBUG_FILE env-var:

Without these two extra -kickuplist and -hyperdebug parameters :

XEMU_DEBUG_FILE=debug1.log ./build/bin/xmega65.native -loadcram ../mega65-core/bin/COLOURRAM.BIN -skipunhandledmem -newhack -8 ../mega65-ide/M65IDE.D81
With these two extra -kickuplist and -hyperdebug parameters:

XEMU_DEBUG_FILE=debug2.log ./build/bin/xmega65.native -loadcram ../mega65-core/bin/COLOURRAM.BIN -skipunhandledmem -newhack -8 ../mega65-ide/M65IDE.D81 -kickuplist ../mega65-core/kickstart.list -hyperdebug

I did a diff between the debug1.log and debug2.log files, and I saw that this sort of extra output gets added into debug2.txt (the one with the extra two parameters):

DMA: initiation of ENCHANCED MODE DMA!!!!

DMA: list address is $FFFA83A now, just written to register 0 value $3A @ PC=$A7E2
HYPERVISOR-DEBUG: A9 01 LDA #$01 PC=A7E2 SP=BEFB B=BF A=3A X=00 Y=00 Z=00 P=nvE-dIzC IO=3 OPC=A9 @ kickstart.a65:1781

DMA: enhanced option byte $0A read
DMA: enhanced option byte $00 read
DMA: end of enhanced options

DMA: READ COMMAND: $0000400[MEM 1:0] -> $0000404[MEM 1:0] (L=$07CC) CMD=0 (CHAINED)
HYPERVISOR-DEBUG: A9 01 LDA #$01 PC=A7E2 SP=BEFB B=BF A=3A X=00 Y=00 Z=00 P=nvE-dIzC IO=3 OPC=A9 @ kickstart.a65:1781

DMA: end of operation, but chained!
DMA: enhanced option byte $00 read
DMA: end of enhanced options

DMA: READ COMMAND: $0000001[MEM 1:0] -> $0000800[I/O 1:0] (L=$07D0) CMD=3 (CHAINED)

DMA: end of operation, but chained!
DMA: enhanced option byte $00 read
DMA: end of enhanced options

DMA: READ COMMAND: $0004000[MEM 1:0] -> $0004000[MEM 1:0] (L=$6000) CMD=0 (LAST)
HYPERVISOR-DEBUG: A9 01     LDA   #$01             PC=A7E2 SP=BEFB B=BF A=3A X=00 Y=00 Z=00 P=nvE-dIzC IO=3 OPC=A9 @ kickstart.a65:1781
HYPERVISOR-DEBUG: A9 01     LDA   #$01             PC=A7E2 SP=BEFB B=BF A=3A X=00 Y=00 Z=00 P=nvE-dIzC IO=3 OPC=A9 @ kickstart.a65:1781
HYPERVISOR-DEBUG: A9 01     LDA   #$01             PC=A7E2 SP=BEFB B=BF A=3A X=00 Y=00 Z=00 P=nvE-dIzC IO=3 OPC=A9 @ kickstart.a65:1781

Ah ok, I think the penny is dropping, all three of these things need to be used in unison (XEMU_DEBUG_FILE + -kickuplist + -hyperdebug) and then you will get these extras in the debug file.

On Sunday, 18 February 2018 14:35:31 UTC+11, Gurce Isikyildiz wrote:

Hiya Gabor,

LGB Gábor Lénárt

unread,

Feb 18, 2018, 1:50:38 AM2/18/18

to MEGA65 Development

Hi,

That XEMU_DEBUG_FILE env. variable controls the debug log. It works without the hypervisor debug feature too, it controls what would get into that file done in source level DEBUG(...) or DEBUGPRINT(...), the second is also prints on the screen. Hypervisor debug option just increase the verbosity to the log file a lot as you noted as well.

Gurce Isikyildiz

unread,

Feb 18, 2018, 2:28:24 AM2/18/18

to MEGA65 Development

Thanks for the confirmation Gabor.

Now I had a q for Paul :)

Paul, earlier in this thread, you mentioned you had a technique to debug serial output. I thought I'd give that a test. I tried using the MONITOR program in C65-mode, then jumping into C64-mode to run it:

MONITOR
A C000 LDA #$7C
LDY #$21
STA $D640
NOP
RTS

X

GO64

SYS 49152

But sadly I didn't see anything in the serial comms output. I pushed a fairly new bitstream onto the device.

MEGA65 Serial Monitor
build px100m,ae2dadb+DIRTY,20180210.10

Any ideas where I went wrong?

LGB Gábor Lénárt

unread,

Feb 18, 2018, 5:16:44 AM2/18/18

to MEGA65 Development

I know I am not Paul :) but monitor actually never worked for me. I guess it also needs some BANK stuff, as basic SYS does also. I've tried to say BANK 0 and BANK 128 before starting monitor but same, nothing happens or crash after sys. Also it's maybe tricky since $C000 is often used to map "interface ROM" in C65 mode by VIC-III btw, but it didn't worked for me either with eg $8000. This was my first adventure with C65 monitor command, and I stop tried to use that ever, since it seems never works for me at least, or I don't know how it should be used ...

Hmm just tried, it actually worked!!!!

MONITOR
A 000800 INC $D020
INC $D021
RTS
X

BANK 128
SYS 2048

Surely at $800 you write the video ram, so you must be careful not to scroll the screen to loose your code ;-P So it seems it's still some banking secret, that you must aware where to put your code to!!

LGB Gábor Lénárt

unread,

Feb 18, 2018, 5:27:00 AM2/18/18

to MEGA65 Development

Oh, and actually in monitor the first two hex digits in address should be the BANK, ie you can say even "A 80C000" but for me it also gives some kind or ROM it seems. Somehow it's realted to BANK 128, I guess ($80 for bank), but it's still not clear for me, how I can use monitor in BASIC to have _ONLY_ RAM without disturbing ROMs everywhere, but I/O enabled still ... Ie it's not possible for me at least to put code to $C000 since there is something there always I tried some bank values though ...

And btw, your example may need first to enable VIC-IV I/O mode anyway.

Gurce Isikyildiz

unread,

Feb 18, 2018, 6:02:04 AM2/18/18

to MEGA65 Development

Thanks for sharing your successes with the monitor command Gabor. I wasn't aware of that BANK command in basic, so glad that you put it on my radar.

That reminds me, I still need to re-read that memory io-map stuff from the c65 manual again, all those details haven't sunk into my brain yet. I'd also better re-read your blog post on the matter too. I tried before, but the details got overwhelming on my last effort.

I find I need to re-read something 10 to 20 times (along with dabbling with the concepts on the hardware as I go along) before it all starts to finally make sense. Maybe that can be my journey for next weekend :)

LGB Gábor Lénárt

unread,

Feb 18, 2018, 3:36:17 PM2/18/18

to MEGA65 Development

https://github.com/lgblgblgb/xemu/commit/02e76cd6bdbaa1b98f0637f33b4f997dffcec40b

Some hack for providing the "keeping busy all the time" policy in case of unaligned access done by KS to check if the card is SDHC. It seems really cures the problem to be able to "boot" with new KS. However it's still strange for me, that KS relays on BUSY flags to do this, it would be more logical to check the error flags ... Also there is some debug now (also printed on stdout even without debug enabled) to see, if any M65 software (including KS for sure) does unaligned access (so it's normal now that you get ONE warning, part of KS' s detection) or trying to set SDHC mode on (since Xemu does not support that, so this debug msg should not even appear ever in normal circumstances).

Gurce Isikyildiz

unread,

Feb 19, 2018, 3:21:36 AM2/19/18

to MEGA65 Development

Thanks Gabor, jumping back to your repo :)

I've kept looking into that MONITOR example and made some progress with it. I'll share below.

As this technique that Paul offered for serial debug output was a trap (a topic I wasn't too familiar with), I remember bumping into trap usage in the "diskmenu.a65" tool... I had a look in the code there, because I suspected that I was missing something, and I think I'm missing this bit:

;-------------------------------------------------------------------------------
initM65IO:
;-------------------------------------------------------------------------------
; Enable enhanced registers
    LDA   #$47      ;M65 knock knock
    STA   $D02F
    LDA   #$53
    STA   $D02F

    RTS

Aah, ok, let me add that to my example then...

MONITOR
A C000 LDA #$47
STA $D02F
LDA #$53
STA $D02F
NOP
NOP
LDA #$7C
LDY #$21
STA $D640
NOP
RTS

X

GO64
Y

SYS 49152

Ah awesome, I stepped through this and the trap stuff triggered and went to this part of the code! :)

> /home/gurce/mega65/mega65-core/src/kickstart_dos.a65:204
> 194:  .word trap_task_toggle_rom_writeprotect
> 195:  .word invalid_subfunction
> 196:  .word invalid_subfunction
> 197:  .word invalid_subfunction
> 198:  .word invalid_subfunction
> 199:  .word invalid_subfunction
> 200:  .word trap_serial_monitor_write
> 201:  .word reset_entry
> 202:
> 203: trap_serial_monitor_write:
> 204:  STY $D67C
> 205:  jmp return_from_trap_with_success
> 206:
> 207: ;        ========================
> 208:
> 209: trap_task_toggle_rom_writeprotect:
> 210:  LDA     hypervisor_feature_enables
> 211:  EOR     #$04
> 212:  STA     hypervisor_feature_enables
> 213:  jmp     return_from_trap_with_success
> 214:

Awesome, the trap triggered :) I tried to catch the serial debug output via minicom terminal with:


minicom -D unix#/home/gurce/mega65/xemu/uart.sock -b 2000000

But sadly no output seen... I'm suspecting that xemu doesn't support this form of hypervisor-debug serial output as yet...

So I tried it on the nexys hardware just now, and awesome, it worked!

Each time I typed "SYS 49152", I saw an additional "!" appear in the terminal window :)

Cool bananas :) Ok, so the only thing I'm missing is this same behaviour in xemu. I might have a tinker with xemu to see if I can replicate this behaviour.

This could end up being a really nice debug facility for me while debugging m65-ide, as it's a C-app (written for cc65), and as m65dbg doesn't support debugging cc65 apps yet, so my alternate approach was to pump out debug strings out the serial port to help me debug the app :)

Auto Generated Inline Image 1

LGB Gábor Lénárt

unread,

Feb 19, 2018, 3:40:55 AM2/19/18

to MEGA65 Development

Hi,

Hypervisor debug serial output is supported by Xemu, but maybe not the same way as nowadays should be, and even back to then, it was different from a real M65. If you launch Xemu now with the *OLD* KS, make sure you use this command line switch: -fpga 12

Hypervisor serial output: "$9047 A:20, X:04, Y:10, Z:03, P:35 : drce_not_eof CHECK<1/3>                                     ".
Hypervisor serial output: "$906C A:0A, X:04, Y:10, Z:03, P:35 : drce_not_eof CHECK<2/3>                                     ".
Hypervisor serial output: "$9094 A:47, X:04, Y:10, Z:03, P:35 : drce_not_eof CHECK<3/3>                                     ".

You will see messages like this on the stderr (no, not via the monitor socket! and stderr not stdout just in case for easier redirection of that separately). This is actually the hypervisor debug serial output. -fpga 12 is an option to emulate that switch#12 on the Nexys board is switched on. And those messages are from the KS, used to provide debug info if switch#12 is turned on. New KS maybe does not do this, ie not use FPGA switch 12 any more for this purpose, but anyway it's just that it produce debug info on that request, till if nothing changed how to push those debug info, you may be able to produce output yourself too. Just keep in mind, that you need to watch the stderr of xemu binary, not the serial uart emulated stuff, that is for only debugging (yes, on M65 they're common stuff, but it would be hard to solve that problem in Xemu well enough this way).

Other than that, it's important to tell, that Xemu buffers the output till a new line. You won't see anything, till a newline character is sent, when Xemu will show the whole buffered line it got till that point, and on the stderr of course. Again, this is because Xemu's nature being an emulator, it would be hard to mix other output of the emulator if char-by-char behaviour would be the same. You may want to have a look on hypervisor.c function hypervisor_serial_monitor_push_char(). Xemu's emulation of the monitor socket is restricted to the monitor features, and cannot be mixed with other "async" function like hypvervisor debug serial output.

Gurce Isikyildiz

unread,

Feb 19, 2018, 4:58:55 AM2/19/18

to MEGA65 Development

Thanks Gabor for the insights!

I was able to get it working by running xemu with the -fpga 12 parameter that you suggested. I then extended my monitor example to include a newline character:

MONITOR
A C000 LDA #$47
STA $D02F
LDA #$53
STA $D02F
NOP
NOP
LDA #$7C
LDY #$21
STA $D640
NOP

LDA #$7C
LDY #$0A
STA $D640
NOP

RTS

X

GO64
Y

SYS 49152

Awesome, now every time I run "SYS 49152", I see this in the xemu console:

Happy with this, will make debugging a lot easier! Thanks for your input again! :)

Auto Generated Inline Image 1

LGB Gábor Lénárt

unread,

Feb 19, 2018, 5:57:00 AM2/19/18

to MEGA65 Development

Ok then :) Actually, if you prefer, you can modify the mentioned function in hypervisor.c, so it can write into a separated file (in case of stdio line buffered stuff like situation, you may want to fsync it though), so you can have a "clean" output char-by-char (that function gets the byte in a parameter, but you can even delete the body of the function and write your own code to do with that byte whatever you want, it does not matter ..), and not line buffered. But, if you have anyway a routine to send "debug marks" like with that SYS 49152 example, you may be OK this way, since then you need to put an extra new line char sending so you can see the output.

Gurce Isikyildiz

unread,

Feb 19, 2018, 7:07:39 AM2/19/18

to MEGA65 Development

I should be fine for now, I'm happy to just add a newline at the end of my debug text, less for me to stress about that way :)

Ok, I gave this idea a try by adding a send_debug() test function inside mega65-ide's "main.c" file:

unsigned char mybyte;

#pragma optimize(off)
void send_debug(void)
{
  char s[20] = "Hello world!\n";
  int k;

  // init M65 IO
  POKE(0xd02f,0x47);
  POKE(0xd02f,0x53);

  for (k = 0; s[k] != '\0'; k++)
  {
    mybyte = s[k];
    __asm__ ( "lda #$7C" );
    __asm__ ( "ldy %v", mybyte); // (unsigned char)s[k]);
    __asm__ ( "sta $D640" );
    __asm__ ( "nop" );
  }

  // reset it back to normal?
  //POKE(0xd031,0);
  // VIC-II IO mode
  //POKE(0xd02f,0);
}
#pragma optimize(on)

I learnt that I needed to turn optimisation off for the inline assembly to work properly.

The results were a little sub-par though. In the xemu console stderr output, I see:

Hypervisor serial output: "LLO WORLD!".

So, it's missing the first two letters of "HE".

I tried stepping through send_debug() with m65dbg, it seems like something went wrong with how the cc65 compiler accessed this string, so I'll have to get better acquainted with cc65 to figure out what made it unhappy...

Ah well, getting closer... :)

LGB Gábor Lénárt

unread,

Feb 19, 2018, 11:32:32 AM2/19/18

to MEGA65 Development

Interesting, you may want to assembly output from cc65 what it does. But anyway, maybe it's worth to put the actual trap stuff to write a single byte into a separated function, so it's then harder for cc65 to mess it up when it sees it's inside a loop. Or you can write that function in assembly in an *.s file actually compile then with ca65 and linked into the project then, maybe ...

Paul Gardner-Stephen

unread,

Feb 19, 2018, 11:33:05 AM2/19/18

to Gurce Isikyildiz, MEGA65 Development

CC65 with optimisation off will optimise away one of the writes to $D02F, since another follows it without a read in between, so it thinks it is useless and can be "optimised" away.

Paul.

--

You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

LGB Gábor Lénárt

unread,

Feb 19, 2018, 12:01:28 PM2/19/18

to MEGA65 Development

Unfortunately, even with no optimization, cc65 sees that you write the same address without using the result which is "useless" in its scope. As far as I remember this is even stated in the documentation that it's no way to work around this too much.

"Note: Inline assembler statements are subject to all optimizations done by the compiler. There currently is no way to protect an inline assembler statement -- alone -- from being moved or removed completely by the optimizer. If in doubt, check the generated assembler output; or, disable optimizations (for that function)."

But that's interesting, that switching optimization off does not help either.

What I would do, is trying to put only the output of a single byte into a separate function and calling that then. Or even better, code that primitive in an assembly source, assemble with ca65 and then link into your project. So cc65 will use your function that was never a C code compiled by itself, no chance that it could mess it up ;-P From just seeing the asm output of a test c file, I guess it would something like this:

.segment        "CODE"
.export _myfunc
.proc   _myfunc: near
.segment        "CODE"
        jsr     pusha
        ldy     #$00
        ldx     #$00
        lda     (sp),y
        sta     _global_ch
        jsr     incsp1
        rts
.endproc

Then you need to declare the prototype of the C function in C at least, ie:

void __near__ myfunc (unsigned char);

or such. Or even better you can try the __fastcall__ stuff, which uses to pass the first arg of the function in a CPU register, not even using stack then.

LGB Gábor Lénárt

unread,

Feb 19, 2018, 12:14:50 PM2/19/18

to MEGA65 Development

Oh, for sure, for fastcall, the asm source must be modified.

Gurce Isikyildiz

unread,

Feb 20, 2018, 3:28:03 AM2/20/18

to MEGA65 Development

Thanks for your input Gabor, Paul,

I'll try and put your thoughts into practice soon. I think I'm a bit mentally depleted today so might take a breather and tackle this next step when I have more wind in my sails.

It's been pretty cool to see how a c-compiler works for the c64. I never had the opportunity to see this language in action on this platform before. I used to read magazine articles back in the day, hearing about how c-compilers existed for the c64, but never had the opportunity (or inclination) to try one till now.

Gurce Isikyildiz

unread,

Apr 3, 2018, 2:48:03 AM4/3/18

to MEGA65 Development

All this recent c64 mini excitement made me want to catch up with where I left off with this task :)

I had a look at my issue of the truncated serial output previously:

Hypervisor serial output: "LLO WORLD!".

Then by chance, I managed to get it to work properly by tweaking the line from send_debug() as follows:

FROM:  char s[20] = "Hello world!\n";
TO:    char s[20] = "hello world!\n";

Aah, so it seems like the capital letter 'H' screwed up the prior string for me, as now I get the proper serial output of:

Hypervisor serial output: "HELLO WORLD!".

Nice, this'll help with the c-debugging adventures ahead... :)

LGB Gábor Lénárt

unread,

Apr 16, 2018, 8:20:25 PM4/16/18

to MEGA65 Development

On Tuesday, April 3, 2018 at 8:48:03 AM UTC+2, Gurce Isikyildiz wrote:

I had a look at my issue of the truncated serial output previously:
Hypervisor serial output: "LLO WORLD!".
Then by chance, I managed to get it to work properly by tweaking the line from send_debug() as follows:
FROM:  char s[20] = "Hello world!\n";
TO:    char s[20] = "hello world!\n";
Aah, so it seems like the capital letter 'H' screwed up the prior string for me, as now I get the proper serial output of:
Hypervisor serial output: "HELLO WORLD!".

That's funny. If it's a cc65 compiled stuff, I think, the problem: cc65 maps characters to PETSCII maybe. So when Xemu prints the result it may be an unprintable control character for your PC what runs Xemu. But you can check, if you redirect stderr of xemu with eg 2> file and you examine the file with a hex editor ;-P Xemu really just prints it, it's certainly a problem if it's not ASCII text too much ... At least this is my guess here.

Ok, I've written a small test program and compiled with cc65, it seems capital ASCII 'H' is translated as $C8 byte value. And that's really it is according to PETSCII. However for a modern eg Linux console/terminal which using UTF-8 it's a problem, since every character above US-ASCII (>127 in value) signals multi-byte encoded unicode position. So It's possible that actually $C8 with the next byte $45 (what meant to be 'e') is treated as some exotic unicode position for a modern OS, so you won't see the 'He' part (and even if you would, some other strange thing would appear there - or better say, it's invalid sequence since next byte should have bit 7 set, anyway, something invalid for utf8 mode console, that's the point).

Paul Gardner-Stephen

unread,

Apr 16, 2018, 8:53:34 PM4/16/18

to LGB Gábor Lénárt, MEGA65 Development, Holger Banko

Hello,

So we should do PETSCII->ASCII conversion before printing the messages out I guess?

Meanwhile, Holger (in CC) is having some trouble running Synthmark64 and some other programs under the latest Xemu. Perhaps you can help him figure out what is going wrong.

Paul.

LGB Gábor Lénárt

unread,

Apr 17, 2018, 4:31:02 AM4/17/18

to MEGA65 Development

Hi,

On Tuesday, April 17, 2018 at 2:53:34 AM UTC+2, Paul Gardner-Stephen wrote:

Hello,

So we should do PETSCII->ASCII conversion before printing the messages out I guess?

I really don't know. It's a hard question, out of context (Mega65) too. With C64, I often struggle with the problem that I want to write a program in assembly, with string meant to be copied to the screen memory, thus encoding (in the final binary) should be "screen codes". If I want to use ROM routines, it should be PETSCII (but then, lower charset or upper+gfx one to encode?). In some cases, cross-platform stuffs come in even on C64, thus better to use ASCII. You see ... Surely the same applies to C too. And on M65 too, or there it's even more serious problem just because we're more often in the situation in modern days to interact between the Commodore world and the "new ASCII world" especially with things like hypervisor debug output, generated by M65 software but displayed one a PC. If you automatically convert here, it may ruins some situation where the expected behaviour is translation-less, being even "8 bit clean". For the cc65 toolchain, I really think, there should be a way to signal string encoding, like something used in Python ie u"something" to signal encoding with that 'u' prefixed with the string, so the compiler (ok, in python's case: interpreter ...) knows how to represent that string. But OK, I think, this topic leads just too far from the original topic - and also it's more a generic problem now with toolchains too not just the hardware, etc. Maybe some trade off would be: allow a bit flag to set up conversion enabled/disabled at least. But it's also true that maybe it's not so much a frequent problem, with hypervisor debug, it's a special case (kind of) not used in every program, it's perfectly normal to just use strings like "hello" in cc65 sources and getting "HELLO" on PC, or write a little routine to send the debug messages with software conversion, it's not so widely used or performance critical. At least, this is my opinion.

To be honest, I often feel to just use ASCII and define my charset (it's even enough to just copy some parts of the charset) and that's fine, I use ASCII even is screen RAM ;-P

Meanwhile, Holger (in CC) is having some trouble running Synthmark64 and some other programs under the latest Xemu. Perhaps you can help him figure out what is going wrong.

Surely, if I know details, etc!

Paul Gardner-Stephen

unread,

Apr 17, 2018, 5:18:33 AM4/17/18

to LGB Gábor Lénárt, MEGA65 Development

Hello,

There is a way to stop cc65 from messing up the codes, but I can't remember how. Part of the trouble is if you fix it that way, then it fixes it for all uses of strings, which might not be what you want.

How about this for an idea:

If a string printed out is unambigiously PETSCII, i.e., would not be valid UTF8, then we can be fairly sure it is PETSCII, and displaying on the debug output it is therefore reasonable to show it converted to ASCII. You could have a command line argument to enable/disable this behaviour in Xemu, so that if you really want it raw, it is possible.

Paul.

LGB Gábor Lénárt

unread,

Apr 17, 2018, 9:44:58 AM4/17/18

to MEGA65 Development

Hi,

On Tuesday, April 17, 2018 at 11:18:33 AM UTC+2, Paul Gardner-Stephen wrote:

Hello,

There is a way to stop cc65 from messing up the codes, but I can't remember how. Part of the trouble is if you fix it that way, then it fixes it for all uses of strings, which might not be what you want.

I'm not sure, for ca65 assembler, there is .CHARMAP or whatever it is, you can re-define any character mapping position (still, some other assemblers are better in this case giving separate pseudo statements to define byte string with ASCII, PETSCII and screen codes without to worry to set/change mode etc, I like that approach better somehow) but it's kinda awkward since it's per character stuff, needing some .REPEAT stuff etc to do it for a range. For cc65 and C hmm, maybe some #pragma, I am really not sure.

How about this for an idea:

If a string printed out is unambigiously PETSCII, i.e., would not be valid UTF8, then we can be fairly sure it is PETSCII, and displaying on the debug output it is therefore reasonable to show it converted to ASCII. You could have a command line argument to enable/disable this behaviour in Xemu, so that if you really want it raw, it is possible.

Fair enough, for sure. My only problem that if you ever encounter a non-US-ASCII char on the output (eg it must be PETSCII) you flag the converting from that point, but it also means that if you start another program the conversion is applied from that point since the first PETSCII-only char value triggered the conversion flag to be enabled. Also, it can be strange to alter the output, eg:

A.) program "hello" (PETSCII) --------> output "HELLO" (ASCII, no conversion, since "hello" as PETSCII can be interpreted as ASCII "HELLO" without problem)
B.) program "Hello" (PETSCII) --------> output "Hello" or "HELLO" or "hello" (whatever conversion we do after encounter PETSCII 'H' which is outside of US-ASCII byte range so it triggers the conversion mode enabled at this point and further messages)
C.) program "hello" (PETSCII, again, as event A) ---> output "hello (maybe, and that's different from event A with the very same input, as conversion flag enabled already).

Now, the strange thing, if the VERY same debug message sent as the A.) event then it will have different output on your PC as the conversion already applied. Or do you mean that only non-US-ASCII chars are converted not the others? The problem that usually (in case lower+upper case charset) PETSCII lower case should be converted in byte values for ASCII otherwise they will be capitalized. Well, I am really struggle here to explain my problem in English, hopefully you got my point.

But anyway, of course it's virtually no work at all to do this in Xemu with any option, the real question: how it should be implemented really. Maybe that can be a policy too, for avoid ANY confusion that hypervisor output should ALWAYS mean capital letters (for example) in PC-ASCII. But surely it means that even "Hello" in PETSCII will be "HELLO" in ASCII then on your PC. But at least we should not worry about the "trigger" enable/disable or anything other. Even if the user writes 65xx asm code in ASCII (not PETSCII) it would work, just maybe capitalized result on hypervisor debug. But at least that is consistent then with all situations?

Paul Gardner-Stephen

unread,

Apr 17, 2018, 6:31:07 PM4/17/18

to LGB Gábor Lénárt, MEGA65 Development

Hello,

re startup mode, this will likely be made configurable in MEGA65 Config Utility, so people can have menu, C65, C64 or M65 or whatever they want each time.

As for the PETSCII/ASCII problem, I still think having a command line option that lets the user indicate how they want things handled is the safest. It can default to current behaviour, but have a -p2a option or similar, that tells it to assume it is PETSCII and convert always to ASCII. If they don't want to use it, they don't have to use it.

Paul.

LGB Gábor Lénárt

unread,

Apr 18, 2018, 8:17:39 AM4/18/18

to MEGA65 Development

-hyperserialascii option is implemented in Xemu (well, I guess I should use shorter names for options ...). It tries convert any possible alphabet range (ASCII+PETSCII lower/upper case) to ASCII upper case only. Surely it's maybe not ideal, but it's not possible too much to do better without knowing that encoding actually used by the program run on M65. Other characters with >0x80 value are replaced with '?' which may left after the conversion.

Paul Gardner-Stephen

unread,

Apr 18, 2018, 3:52:14 PM4/18/18

to LGB Gábor Lénárt, MEGA65 Development

well done!

On 18 April 2018 at 21:47, LGB Gábor Lénárt <lgbl...@gmail.com> wrote:

-hyperserialascii option is implemented in Xemu (well, I guess I should use shorter names for options ...). It tries convert any possible alphabet range (ASCII+PETSCII lower/upper case) to ASCII upper case only. Surely it's maybe not ideal, but it's not possible too much to do better without knowing that encoding actually used by the program run on M65. Other characters with >0x80 value are replaced with '?' which may left after the conversion.

--

Gurce Isikyildiz

unread,

Apr 19, 2018, 3:12:53 AM4/19/18

to MEGA65 Development

Heya all,
I've been a little slack and haven't followed through all nuances the latest ASCII+PETSCII tweaks to xemu, but I'll try catch up soon :)

Just wanted to share info on an update to m65dbg. I can finally step through c-code from cc65 (in a way) via m65dbg. It's pretty rough, but it'll do for now.

I'll try jot down some steps to replicate:

Get my tweaked cc65 (I made a tweak to improve .list file support)
- Open a console (or new console tab)
- cd somebasepath
- git clone g...@github.com:gurcei/cc65.git
- cd cc65
- make
- sudo make avail
Get my tweaked m65ide (has my send_debug() output additions)
- Open a console (or new console tab)
- cd somebasepath
- git clone g...@github.com:gurcei/mega65-ide.git
- cd mega65-ide
- make (NOTE: this needs to compile with my tweaked cc65)
Get Gabor's latest xemu and run M65IDE in it
- Open a console (or new console tab)
- cd somebasepath
- git clone g...@github.com:lgblgblgb/xemu.git
- cd xemu
- make
- build/bin/xmega65.native -hyperdebug -loadcram ../mega65-core/bin/COLOURRAM.BIN -skipunhandledmem -newhack -8 ../mega65-ide/M65IDE.D81 -fpga 12
- In xemu's initial popup windows, choose "Use external D81 image file"
- It should jump straight to c64 basic
- Press Shift+Esc to load up m65-ide inside xemu
- Once it loads, we can try debugging via m65dbg...
Get latest m65dbg
- Open a console (or new console tab)
- cd somebasepath
- git clone g...@github.com:MEGA65/m65dbg.git
- cd m65dbg
- make
- sudo make install
Run m65dbg from the mega65-ide path to debug it
- cd somebasepath
- cd mega65-ide
- m65dbg -l unix#../xemu/uart.sock

Ok, now we can try debugging things:

Do some init commands if needed (you can add such commands into your "~/.m65dbg_init" file if you want them typed automatically on each run):

autocls 1
autowatch 1
Then try:

break _line_fetch (when referencing c-functions such as line_fetch(), ca65 prefixes a "_" char into their symbol names)
c (for continue)
Jump to the xemu window and push the down arrow key (this will trigger the line_fetch() function)
Back in m65dbg, you will get a disassembly for where it just hit the break:

PC   A X Y Z B SP   MAPL MAPH LAST-OP     P P-FLAGS   RGP uS IO
4D94 00 00 04 00 00 01E6 0000 0000 20       22 00 --E---Z-
---------------------------------------
no watches in list
---------------------------------------
$4D94      M_impl:0 48       PHA
<dbg>

Hmm, this isn't where we hoped for, but not to worry, it's because the hardware breakpoints will stop the CPU at the instruction *after* the breakpoint, and for a JSR instruction, that will be within the JSR subroutine itself.
Not to worry, let's do a "down" instruction to drop down the stack a level. Now we see:

---------------------------------------
no watches in list
---------------------------------------
<<< FRAME#: 1 >>>
> m65ide.list:5975
> 5965: 0003FAr 1
> 5966: 0003FAr 1               .segment        "CODE"
> 5967: 0003FAr 1
> 5968: 0003FAr 1               .proc   _line_fetch: near
> 5969: 0003FAr 1
> 5970: 0003FAr 1               .segment        "CODE"
> 5971: 0003FAr 1
> 5972: 0003FAr 1               ;
> 5973: 0003FAr 1               ; {
> 5974: 0003FAr 1               ;
> 5975: 0003FAr 1 20 rr rr             jsr     pushax
> 5976: 0003FDr 1               ;
> 5977: 0003FDr 1               ; send_debug("line-fetch(line=%d)", line_number);
> 5978: 0003FDr 1               ;
> 5979: 0003FDr 1 20 rr rr             jsr     decsp5
> 5980: 000400r 1 A9 rr                lda     #<(L00F2)
> 5981: 000402r 1 A2 rr                ldx     #>(L00F2)
> 5982: 000404r 1 20 rr rr             jsr     pushax
> 5983: 000407r 1 A0 0A                ldy     #$0A
> 5984: 000409r 1 20 rr rr             jsr     pushwysp
> 5985: 00040Cr 1 A0 04                ldy     #$04
---------------------------------------
$2328      M_nnnn:2 20 94 4D JSR $4D94
<dbg>
- Notice how we now see the source of the "m65ide.list" file.
- I gave the cc65 compiler the "--add-source" parameter so that it embeds each line from the c-source code into the generated assembly as a comment.

I can then set a breakpoint further along in this code by line-number and continue to it:

break :5980
c

PC   A  X  Y  Z  B  SP   MAPL MAPH LAST-OP     P  P-FLAGS   RGP uS IO
2330 83 00 00 00 00 01E8 0000 0000 A9       A1 00 N-E----C
---------------------------------------
no watches in list
---------------------------------------
> m65ide.list:5981
> 5971: 0003FAr 1
> 5972: 0003FAr 1               ;
> 5973: 0003FAr 1               ; {
> 5974: 0003FAr 1               ;
> 5975: 0003FAr 1  20 rr rr             jsr     pushax
> 5976: 0003FDr 1               ;
> 5977: 0003FDr 1               ; send_debug("line-fetch(line=%d)", line_number);
> 5978: 0003FDr 1               ;
> 5979: 0003FDr 1  20 rr rr             jsr     decsp5
> 5980: 000400r 1  A9 rr                lda     #<(L00F2)
> 5981: 000402r 1  A2 rr                ldx     #>(L00F2)
> 5982: 000404r 1  20 rr rr             jsr     pushax
> 5983: 000407r 1  A0 0A                ldy     #$0A
> 5984: 000409r 1  20 rr rr             jsr     pushwysp
> 5985: 00040Cr 1  A0 04                ldy     #$04
> 5986: 00040Er 1  20 rr rr             jsr     _send_debug
> 5987: 000411r 1               ;
> 5988: 000411r 1               ; t_old = get_start_time();
> 5989: 000411r 1               ;
> 5990: 000411r 1  20 rr rr             jsr     _get_start_time
> 5991: 000414r 1  A0 01                ldy     #$01
---------------------------------------
$2330     M_immnn:1 A2 54    LDX #$54
<dbg>

...and there ya go, it hit the breakpoint and is waiting at the next instruction/line after this (:5981)

Anyway, that's just a little sampler of where it's at right now. It's a bit rough, but it's a start :)

I'm hoping it'll help me when it comes to debugging m65ide :)

On Thursday, 19 April 2018 05:52:14 UTC+10, Paul Gardner-Stephen wrote:

well done!

On 18 April 2018 at 21:47, LGB Gábor Lénárt <lgbl...@gmail.com> wrote:

-hyperserialascii option is implemented in Xemu (well, I guess I should use shorter names for options ...). It tries convert any possible alphabet range (ASCII+PETSCII lower/upper case) to ASCII upper case only. Surely it's maybe not ideal, but it's not possible too much to do better without knowing that encoding actually used by the program run on M65. Other characters with >0x80 value are replaced with '?' which may left after the conversion.

--
You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

LGB Gábor Lénárt

unread,

Apr 19, 2018, 3:43:49 AM4/19/18

to MEGA65 Development

Hi,

Interesting, Especially the modified CC65 idea. Once, I've tried to rewrite Mega65 kickstart for CA65 and it worked, however exactly the problem is the lack of decent tool to produce the Ophis-like list file useful for debugging the KS. It seems CC65 suite internally knows a LOT about things but quite hard to export into a sane format for debugging (for example od65 can emit a large number of inside information on object files). Maybe a modified cc65 is the way to achieve the goal if Ophis->ca65 change is planned and we still want our sweet debug abilities, with m65dbg?

https://github.com/lgblgblgb/mega65-kickstart-ca65

In relation of Xemu, I'm still thinking how to get rid of some annoying question Xemu asks. When you use the -8 parameter the problem, that if Xemu does not ask that question, it renders D81 "mounting" in M65 impossible since always the external D81 image is selected which is maybe that or maybe not what you want, it would be better to tell it what is the situation, that's the reason of the question. But I've already got the idea that maybe a fake D81 should be placed onto the SD image, which contains some special signature, directing Xemu to use external D81, otherwise the internal, so there would be no additional question any more. Things like this can be interesting from the point of view, if I like a solution to have "automated" testing, ie no need to answer questions or even no need to manually type LOAD (or shift+ESC) and everything should be OK to give as parameter for fast boot-up (also probably utilizing some extended monitor_load feature, to quite match the theory to something similar with the real M65).

Gurce Isikyildiz

unread,

Apr 19, 2018, 7:17:54 PM4/19/18

to MEGA65 Development

Hi Gabor,

Aah, good to learn of your ca65-version of kickstart, I can give it a test-drive with the new m65dbg facilities and see how it fares.

And yep, agreed that if the compilers aren't giving us what we want, let's tweak them so that they give us what we want :D

I'm all for your ideas for streamlining the start-up of xemu to optionally avoid more startup queries and also automatically doing the LOAD command too.

Some other ideas I was thinking of:

I understand how the mega65 hardware's breakpoints behave in such a way that once a breakpoint is hit, the system breaks at the instruction *after* the breakpoint address. I remember Paul explaining the reasons for this somewhere (maybe in his blog posts or in the forums here), that it related to the instruction pipeline in some way?
Ok, fair enough if there are complications with breaking exactly on the address specified on the real hardware, but I'm wondering, could xemu instead break on the exact address specified? I know this deviates from your principal of aiming to emulate the hardware exactly, but on the up-side, it's a much nicer way to debug with breakpoints, and you'd be offering a debugging mechanism that the hardware isn't capable of yet.
My rough solution for using the cc65 .list file isn't ideal, but it'll do for now.
I think in future, I'll need to tweak cc65 to add more hints in the .list file of "this compiled assembly line came from that assembly-source file at line X, and/or that c-source file at line Y"
Hopefully, one day, I can improve m65dbg further to provide some sort of equivalent to gdb's TUI mode (or lldb's "gui" mode), i.e., a text-based gui that has panes to let you comfortably browse the source, view your watches, examine the call-stack, etc. I actually thought lldb's gui mode looked quite cute and friendly:
Ah well, maybe one day in the future. I think this will require me to learn about the "curses" library, I'll be starting the learning curve from zero, so it might take a while to get there... Let's see... But still, I'm enthusiastic about the idea... Having shortcut keys to switch between c-source, assembly-source, c+assembly interleaved and raw disassembly... :)

Gurce

LGB Gábor Lénárt

unread,

Apr 19, 2018, 8:29:57 PM4/19/18

to MEGA65 Development

Hi Gurce,

Indeed, curses/ncurses is kinda a beast and ugly stuff :-O But it's in its origin as well, not even just Linux, but several UNIX'es, control sequences, encodings, terminals, etc, you see :-O Many years ago - for fun - I wrote nc64 which was a C64-emulator with ncurses interface, so you can use even without X, with custom conversion from screen memory to ncurses functions, surely no gfx etc then. But that's another story, and totally meaningless. However I must say, ncurses is really hard to understand sometimes and its API really feels like some ancient UNIX Rosette stone found, sure thing. Maybe it's worth to check alternatives out as well, like libnewt, or maybe slang has something similar what ncurses does? Oh, and slang has something similar too, if I remember well. Interestingly now it's easier to crate a GUI than TUI, GUI is much more standardized (eg X11 is X11 everywhere (unless you move to a higher level widget set like gtk/qt), low level console access/escape seqs, colours etc ... hundreds of them) than terminal console more than just printing text with printf() or such ... Sad thing.

For cc65 list file, for real, it should be but into its linker ... Since that constructs the final binary what we're interested about, not on the per object output file output level created by eg ca65 or cc65 when compiled the given file.

For auto load etc, I think Paul is right, that unifying the solutions used for real M65 and Xemu is nice thing, ie put support into both of Xemu and let's monitor_load supports Xemu too. And then yes, those annoying questions should be eliminates as well, at least in the case when this auto-stuff is used :)

About the breakpoints etc: it's still very problematic and ugly solution in Xemu, i should rewrite many things first there to be sane enough to be able to "play" with it :(

LGB Gábor Lénárt

unread,

Apr 23, 2018, 12:09:40 PM4/23/18

to MEGA65 Development

Hi Gurce,

About this older post of yours ... Now I've open a new branch inside Xemu's repository to try to step forward with full "new KS" compatibility "by default" and other great features of M65 to be emulated.

One interesting thing where I stuck now, and this post of yours remembered me to your experience: how could you choose _any_ option to select utility? For me, nothing reacts neither pressing '1' or '2'. Did it worked for you (it seems)? Now I am curious what's the difference. Could you please try with the latest KS + its utils etc and xemu from the "dev" branch? It still needs -newhack etc though ...

thanks!

On Friday, February 16, 2018 at 7:16:37 AM UTC+1, Gurce Isikyildiz wrote:

Hi guys,

I've been pushing along trying to get the latest kickstart working with the latest xemu, so that I can press on with debugging m65-ide.

Just wanted to share some of my observations along the way. Sorry for the long-windedness.

I've used -newhack argument to my xemu call, to get the new DMA implementation Gabor implemented. That got me to the kickstart screen successfully, awesome:

But if I choose option 2, I get this:

If I choose option 1 though, looks good:

If I then press F10 in xemu (for a soft restart) and then select option 2, it then displays correctly:

I did the "DELETE EVERYTHING" command. I was applying this to a raw/fresh mega65.img file that xemu had offered to autogenerate, so I wasn't worried about losing anything.

However, upon completion, the sd-card is still un-usable. After having a look at the mega65.img file via hexdump, all bytes are still zero, so nothing was written to them.

Ah well, perhaps this could relate to the new dma implementation, so I didn't push much further in that direction.

I instead tried using Gabor's pre-prepared image from online. I'll share how that went.
wget https://raw.githubusercontent.com/lgblgblgb/xemu/gh-pages/files/sd-card-image-for-xemu-xmega65.img.gz
gunzip -k sd-card-image-for-xemu-xmega65.img.gz
mv sd-card-image-for-xemu-xmega65.img "~/.local/share/xemu-lgb/mega65/mega65.img"
But when I use this image and re-run xemu, it still offers the utility menu:

This surprised me somewhat, as I thought that this utility menu should only appear when the alt key is down. After looking at the .a65 source, I learnt it also appears when no disks are found on the sdcard image.

Aah, so that's why the disk-count in the kickstart bootup was showing as zero:

I mounted the mega65.img locally and confirmed it definitely had content on it, and a .D81 file. So then it became a question of why it wasn't being located.

I did some debugging around the readmbr: section of the assembly and confirmed it retrieved the MBR from sector 0 successfully, and it matches what I see in the mega65.img file via dd and hexdump:
dd if=mega65.img bs=1 count=512 2> /dev/null | hexdump -C -v | less
This seems to be the part of interest with the partition info for the 1st partition:
000001b0  00 00 00 00 00 00 00 00  59 88 07 d9 00 00 00 00  |........Y.......|
000001c0  01 20 0c 03 d0 ff 00 08  00 00 00 a0 0f 00 00 00  |. ..............|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
Ok, time to interpret what that all means:

00 00 01 20 0c 03 d0 ff 00 08 00 00 00 a0 0f 00

0c = partition type = FAT32 with LBA (not CHS)
- Aah, since we're using LBA, the CHS fields of this partition entry can be ignored, I think...

00 08 00 00 = LBA of first sector in partition
= 0x00000800
= sector 2048
= 2048 x 512 = 1048576 'th byte

00 a0 0f 00 = Number of sectors in partition
= 0x000fa000
= 1024000 sectors
= 524288000 bytes
= 500 MB

Aah right, so if I do a dd of this 1048576 offset, I can see the boot-sector (VBR) of this 1st partition:
dd if=mega65.img bs=1 count=512 skip=1048576 2> /dev/null | hexdump -C -v | less

00000000  eb 58 90 6d 6b 66 73 2e  66 61 74 00 02 08 38 02  |.X.mkfs.fat...8.|
00000010  02 00 00 00 00 f8 00 00  10 00 04 00 81 00 00 00  |................|
00000020  00 a0 0f 00 e6 03 00 00  00 00 00 00 02 00 00 00  |................|
00000030  01 00 06 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  80 01 29 43 f0 a3 56 4c  4f 55 44 20 20 20 20 20  |..)C..VLOUD     |
00000050  20 20 46 41 54 33 32 20  20 20 0e 1f be 77 7c ac  |  FAT32   ...w|.|
00000060  22 c0 74 0b 56 b4 0e bb  07 00 cd 10 5e eb f0 32  |".t.V.......^..2|
00000070  e4 cd 16 cd 19 eb fe 54  68 69 73 20 69 73 20 6e  |.......This is n|
00000080  6f 74 20 61 20 62 6f 6f  74 61 62 6c 65 20 64 69  |ot a bootable di|
00000090  73 6b 2e 20 20 50 6c 65  61 73 65 20 69 6e 73 65  |sk.  Please inse|
000000a0  72 74 20 61 20 62 6f 6f  74 61 62 6c 65 20 66 6c  |rt a bootable fl|
000000b0  6f 70 70 79 20 61 6e 64  0d 0a 70 72 65 73 73 20  |oppy and..press |
000000c0  61 6e 79 20 6b 65 79 20  74 6f 20 74 72 79 20 61  |any key to try a|
000000d0  67 61 69 6e 20 2e 2e 2e  20 0d 0a 00 00 00 00 00  |gain ... .......|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
So the partition information in the image is legit...

I step through the code around dos_read_partitiontable: and kickstart_dos.a65:728:
; Partitions start at offsets $1BE, $1CE, $1DE, $1EE
; so consider each in turn. Opening the partition causes other sectors to
; be read, so we must re-read the MBR between each

; get pointer to second half of sector buffer so that we can access the
; partition entries as we see fit.
;

lda #<[sd_sectorbuffer+$1BE]
sta dos_scratch_vector
lda #>[sd_sectorbuffer+$1BE]
sta dos_scratch_vector+1

I then see it prepare to read the boot-sector of the first partition, by preparing sd_address_byte0-4 to equate to the sector to read:

#4: DWORD sd_address_byte0: 00000800

...and then calling sd_readsector:

...after this, there is a call to sd_map_sectorbuffer: which I think will drop the sd-sector's contents into sd_sectorbuffer (0xDE00 - 0xDFFF) region of memory.

When it was called previouslky for reading of the MBR, the contents of sd_sectorbuffer were correct.

But after trying to read the 1st sector of the 1st partition, all I get is zeros, that's not right...

:000DE00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DE90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEA0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DED0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DEF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DF90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFA0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFB0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................
:000DFF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

I then took a look inside xemu's "targets/mega65/sdcard.c" to learn how this sdcard reading was done.
I saw sdcard_command() had case 0x02: for reading a block
This called diskimage_read_block() to do this task, feeding it an offset via the sd_sector_bytes parameter (which equated to the correct 0x00000800 offset requested).
Within diskimage_read_block() was a call to host_seek_to() which I then found a point of concern:

if (lseek(fd, image_offset, SEEK_SET) != image_offset)

This image_offset value equated to 0x00000800 (passed in via sd_sector_bytes), which is the correct offset, but in units of sectors. The lseek() function is seeking in units of bytes.

So, to test my theory, I tried editing this line to become:

if (lseek(fd, image_offset*512, SEEK_SET) != image_offset*512)

I ran xemu again, and hey presto! The c65 startup screen is back! No more utility menu! :)

I tried GO64, and load up that default MEGA65.D81 disk image, but the LOAD "$",8 for it just returns:

I'll save that debugging journey of the .D81 file for another time.

LGB Gábor Lénárt

unread,

Apr 23, 2018, 3:41:03 PM4/23/18

to MEGA65 Development

Never mind, sorry about the noise. I found the heart of the problem in Xemu with the hardware accelerated keyboard routines to be defected at last. It seems it's a race condition that new ascii value is stored in an async fashion very rarely (at main SDL event loop), so a tight loop of scanning keyboard causes to have very big change that it writes $D610 before it would read $D610 to get the key ... So I moved to another variable to "submit" the key by event loop, but only do that right when $D610 is read, not at any time in an async way ...

Reply all

Reply to author

Forward