Hi,

I'm experimenting with pushing parts of programs to the language card,
using #pragma code-name (push, "LC") with cc65.

This gives good results on my Apple //c. I get ~3k more heap available,
and everything seems fine.

But the same programs crashes hard when emulated on MAME. I noticed
that the `mame apple2c -listslots` does not list a language card
(contrary to `mame apple2 -listslots`.

Is this wrong, or am I wrong? Is there a way to verify the presence of
that card in my Apple //c?

Thanks in advance,
--
Colin Leroy-Mira

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Colin,

I'm experimenting with pushing parts of programs to the language card,
using #pragma code-name (push, "LC") with cc65.

:-)

This gives good results on my Apple //c. I get ~3k more heap available,
and everything seems fine.

:-))

But the same programs crashes hard when emulated on MAME.

:-(

I noticed
that the `mame apple2c -listslots` does not list a language card
(contrary to `mame apple2 -listslots`.

Is this wrong, or am I wrong? Is there a way to verify the presence of
that card in my Apple //c?

The 16kB Language Card upgraded an Apple ][ from 48kB to 64kB. All later
Apple II came with at least 64kB - meaning that they all contain a "logic" Language Card.

The Apple //c came even with 128kB - meaning that it always contains two "logic" Language Cards.

Apart from that: ProDOS uses 13kB of the 16kB Language Card. So if there's
no "logic" Language Card, ProDOS won't boot at all.

Regards,
Oliver

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

This gives good results on my Apple //c. I get ~3k more heap
available, and everything seems fine.

:-))

But the same programs crashes hard when emulated on MAME.

:-(

Well. In fact, I also have crashes on the real hardware when pushing to
LC. They don't always happen, but I am quite sure there is something
fishy going on even if there's no dropping to the Apple 2's monitor.
Sadly I'm very much not good enough at assembler to figure out if that's something in my code, or something related to pushing code to the
language card.

At the very least, cc65's .s generated files are exactly the same, with
offsets being just one or two off, when using code-name LC and not.

The vast majority of my code runs with absolutely no errors in its
libc/x86-64 form under Valgrind, but I also know that it doesn't make
sure there isn't some stupidity in the rare #ifdef __CC65__ parts, *or*
an integer/signed-unsigned overflow issue somewhere. I probably have an
issue, and it's probably just more visible with code in $D400-DFFF.

I've looked a lot at internet resources to figure out if I could
somehow get some higher level of debugging that I could handle, but
didn't find anything :/ Maybe my only choice is to try to build my
program for c64 and check with vice?

I noticed
that the `mame apple2c -listslots` does not list a language card
(contrary to `mame apple2 -listslots`.

Is this wrong, or am I wrong? Is there a way to verify the presence
of that card in my Apple //c?

The 16kB Language Card upgraded an Apple ][ from 48kB to 64kB. All
later Apple II came with at least 64kB - meaning that they all
contain a "logic" Language Card.

Thanks for confirming that :)
--
Colin Leroy-Mira

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Colin,

Well. In fact, I also have crashes on the real hardware when pushing to
LC. [...]

I can't solve your issue but I can say, that I'm using the LC in that way
in most of my cc65 projects. At least some of my projects are somewhat
popular and I never got any feedback that there would be an issue with that
LC usage. So in contrast to e.g. the serial driver ;-) that LC usage is a
well tested feature.

BTW: Beside the usual optimization related compiler flags you certainly
should consider the --static-locals flag. It makes (non reentrant) code
usually both faster and smaller. The latter may be relevant to if have
space issues.

Regards,
Oliver

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, January 6, 2023 at 9:05:20 AM UTC-8, Colin Leroy-Mira wrote:

But the same programs crashes hard when emulated on MAME.

I've looked a lot at internet resources to figure out if I could
somehow get some higher level of debugging that I could handle, but
didn't find anything :/ Maybe my only choice is to try to build my
program for c64 and check with vice?

Both MAME and AppleWin provide debuggers. You can find a couple of "cheat sheets" here:
https://6502disassembly.com/applewin-dbg.html
https://6502disassembly.com/mame-dbg.html

I'm not sure how they compare to VICE.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Replying to myself...

Yes, actually, maybe my problem comes from the use of both LC and the "less-well-tested" serial driver:

Mmmh, I just moved the ser_install/ser_apple2_slot/ser_open calls out of
the LC code, and it seems to work perfectly now (both on real hardware
and MAME emulation).

Did I just hide my problem again or could it make some sense ?
--
Colin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

fadden said:

Both MAME and AppleWin provide debuggers. You can find a couple of
"cheat sheets" here: https://6502disassembly.com/applewin-dbg.html
https://6502disassembly.com/mame-dbg.html

Thanks, I've started diving into mame and its debugger. I must say it's
quite complicated for me, as I don't know 65C02 assembly - but well,
maybe I'll get somewhere, I may not be too old to learn new stuff!

Oliver said:

I can't solve your issue but I can say, that I'm using the LC in that
way in most of my cc65 projects. At least some of my projects are
somewhat popular and I never got any feedback that there would be an
issue with that LC usage. So in contrast to e.g. the serial driver
;-) that LC usage is a well tested feature.

Yes, actually, maybe my problem comes from the use of both LC and the "less-well-tested" serial driver:
I seem to have noticed that there are memory writes to the D400-DFFF
region when using the serial driver? If this is possible?

But I'm not even sure of my finding, and even then, I don't know why
that would crash, as according to my map file, my code doesn't go as far (D400-D8ED according to the map file) as where those writes happen
(DFB7-DFC8 according to MAME).

I've uploaded a minimal reproducer in case you'd like to look at it and
tell me how I'm wrong - because I probably am, but don't feel any
pressure, I'll figure something out :)

https://colino.net/a2dbg/a2-min.c #for the Apple2 https://colino.net/a2dbg/pc-min.c #for the PC https://colino.net/a2dbg/mame-log.txt #my debugger experiments.

I set the watchpoint when the Apple2 test program has output "any key to install". The writes happen after receiving a character from the PC. If
the PC doesn't reply, or sleeps a few dozens milliseconds before
answering, no write happen to $DFB7-DFC8).
But at some point with my real program, they happen, even with liberal
use of usleep() before replying.

Thanks for reading me anyway, and I'll tell you guys if I make some
progress.

I miss valgrind a lot, haha !

--
Colin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

If you want to share the code, I'd be happy to investigate.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

If you want to share the code, I'd be happy to investigate.

This is very nice of you!

The code is published on my repo at
https://github.com/colinleroy/a2tools

It may be a little annoying to setup, but if you got questions, I can
answer them.

I'm doing a little project of a serial/network proxy for my Apple //c.

There's the server part, that runs on the PC (I'm coding on Linux, I
hope it's portable), in src/surl-server. You start it with
export A2_TTY=/dev/ttyUSB0
export A2_TTY_SPEED=9600
export A2_TTY_HW_HANDSHAKE=1
./src/surl-server

(use A2_TTY_HW_HANDSHAKE=0 if your serial cable only has TX/RX, or
when emulating, depending on your emulator - using MAME, ser2net and a
TCP socket bitbanger, I have to set it to 0.).

And the client part is in src/stp/.
Problems arise very quickly if you put the simple_serial_open() function
of src/lib/simple_serial.c inside the #pragma code-name(push,"LC").

If it's too much of a bother to test, I'll totally understand :)
--
Colin
https://www.colino.net/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Does it still have the crashing problem, though? My message might
have been too late if you've solved it already. :-)

As long as you add -DSERIAL_TO_LANGCARD in src/stp/Makefile's CLCFLAGS,
yes :)

--
Colin
https://www.colino.net/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Does it still have the crashing problem, though? My message might have been too late if you've solved it already. :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Well. In fact, I also have crashes on the real hardware when pushing
to LC. [...]

I can't solve your issue but I can say, that I'm using the LC in that
way in most of my cc65 projects. At least some of my projects are
somewhat popular and I never got any feedback that there would be an
issue with that LC usage. So in contrast to e.g. the serial driver ;-)
that LC usage is a well tested feature.

Holy hell I have figured that out after 48 hours of diving into
assembly!! I'm so proud of myself.

I'll file a bug report to cc65 when I'm rested a bit ! :-)
--
Colin
https://www.colino.net/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Holy hell I have figured that out after 48 hours of diving into
assembly!! I'm so proud of myself.

I'll file a bug report to cc65 when I'm rested a bit ! :-)

Oliver, if you want the details, I wrote about this investigation in https://www.colino.net/wordpress/archives/2023/08/15/tracking-and-killing-a-cc65-corruption-bug/

and I opened a pull request at https://github.com/cc65/cc65/pull/2160

In the hope the resource can help other people debugging for the Apple
II, and also not to forget how I did for the next time I have to do
such a exhausting (for me) debugging session :)

In fact I'd love if you would give a look at the PR, I *think* this is
the correct fix, but I'm not a hundred percent sure.
--
Colin
https://www.colino.net/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Very nice!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Very nice!

Thanks :)
--
Colin
https://www.colino.net/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)