WinAPE status / alternative IDE?

[NJean]

Hello everyone!

I am using WinAPE for a (somewhat silly) development project, and I particularly appreciate the built-in assembler and debugger. However, I'm encountering a few problems:

• Full-screen display in Windows 11 returns an error message (this seems to be a well known bug, so I don't use full-screen mode, but it's still a bit annoying when I accidentally press F10 instead of F9, which happens too often on my very poor HP laptop featuring a light grey keyboard with slightly lighter grey lettering...)
• And above all, I'm at a point where the debugger freezes WinAPE (or, at best, keeps opening error windows...) when it opens on a certain breakpoint... It's likely that I've used something incorrectly, but since WinAPE seems unreasonably trusting of the user (and crashes rather than reporting the problem), I'm a bit stuck!

Despite its great qualities, the WinAPE project has been in version 2.0 beta 2 since 2016: I regret this, but I suppose Richard Wilson has other priorities (and he has every right to; in fact, I would like to take this opportunity to thank him warmly for what he has already accomplished!) It therefore seems unreasonable to hope that these bugs will be fixed...

If I have to give up on WinAPE, I will mourn its loss (painfully) but what "integrated development emulator" would you recommend as an alternative?

Thank you for your advice!

Nicolas

[Brocky]

winape seems to be the go to for dev...

i like JavaCPC desktop, but it has its own quirks

[GUNHED]

Use WinCPC and an assebler which is used by CPC itself. MAXAM for example.
It has a great debugging suite.

[NJean]

winape seems to be the go to for dev...

i like JavaCPC desktop, but it has its own quirks

Thanks for this first answer!

That could be flattering because it means that, in your opinion, I chose the right environment.
But let's be honest: I don't think I gave it much thought, so let's just say that I was lucky to choose the right environment...

On the other hand, that means all I have to do now is figure out why I'm causing the WinAPE debugger to crash... It's specific, but it won't necessarily be much easier than installing a new IDE! 😅

If anyone else has ideas about the future of WinAPE, choosing another IDE, or in-depth knowledge of known WinAPE bugs, I'm still interested 

[NJean]

Use WinCPC and an assebler which is used by CPC itself. MAXAM for example.
It has a great debugging suite.

Thank you very much for this suggestion!

Using a "CPC" development environment seems to be the most heroic (and most authentic) option, but I am afraid it might be a little more difficult than what is possible with the power of an "external" integrated environment.

I should probably have mentioned that my project is a bit complicated. I currently handle around 800 KB of ASM files (admittedly with quite a few comments) Furthermore, for the sake of efficiency, some of the code and data are loaded at compile time into the additional 64 KB of the 6128, while others are written into data files on the (emulated) floppy disk... I fear it could be difficult to manipulate and work with all of this in the (emulated) CPC itself... 

[Johnny Olsen]

Try going to settings (F12)
Display
Full Screen Colours
16 bit (Accuracy)

It works for me..

[NJean]

Try going to settings (F12)
Display
Full Screen Colours
16 bit (Accuracy)
It works for me..

Shame on me , and thank you so much!

This simple setting does indeed fix the famous full-screen display issue in WinAPE...

That leaves 50% of my problem (and perhaps the most embarrassing part): the debugger crashes...
Do you happen to have another miracle option that I could check in the settings? 

[Johnny Olsen]

Have you checked if the debugger still crashes? 
Mine never does

 

[Prodatron]

the debugger crashes...

Good, that the first issue is fixed!

Can you describe how to reproduce the breakpoint crash, or is it crashing in a very random way?
I never had this issue, so I wonder, if you use very special breakpoints.


Maybe an alternative to WinApe could be using the combination of

- AceDL ( https://roudoudou.com/ACE-DL/ ) and
- RASM ( https://github.com/EdouardBERGE/rasm )

both by @roudoudou .
I have no idea, if it is possible to assemlbe directly into the memory of the emulated machine, which I am using a lot in WinApe, but maybe this could be achieved as well.

[NJean]

Can you describe how to reproduce the breakpoint crash, or is it crashing in a very random way?
I never had this issue, so I wonder, if you use very special breakpoints.

I just ran a few more tests and realised that I don't even need to set a breakpoint... For instance:
- assemble the project with CTRL-F9
- open the "symbols" window
- click on the address of one symbol
- the debugger window opens at the given address...
- ...along with a Windows message box: "Access violation at address 0040AED5 in module 'WinApe.exe' Write of address 20202020" [values may vary]

Closing this message box usually causes others to appear, and I eventually have to kill the WinAPE process from the task list...

What I fear (but this is probably unfair to Richard Wilson) is that some WinAPE table has a static limit...

I should probably try to "debug" WinAPE (or at least isolate the bug...) by modifying (pruning) my source code until the problem disappears...

[lightforce6128]

I just ran a few more tests and realised that I don't even need to set a breakpoint... For instance:
- assemble the project with CTRL-F9
- open the "symbols" window
- click on the address of one symbol
- the debugger window opens at the given address...
- ...along with a Windows message box: "Access violation at address 0040AED5 in module 'WinApe.exe' Write of address 20202020" [values may vary]
Closing this message box usually causes others to appear, and I eventually have to kill the WinAPE process from the task list...
What I fear (but this is probably unfair to Richard Wilson) is that some WinAPE table has a static limit...

I faced exactly the same problem, although the program I was working on was by far smaller (but still not small) than the one you described. After several experiments I came to the conclusion that Maxam theoretically allows labels to be arbitrarily long, but that there is somehow a limit in the disassembly window. In my project the error appears as soon as by scrolling I reach a line with a long label.

To test this: Assemble your program, open the disassembly window, and go to an address e.g. 64 bytes away from the suspicious label. Then slowly scroll towards the label position. In the moment its line should get visible, the error will appear. So this seems to be an error in a GUI callback to prepare the lines that should be shown, probably in string processing.

The solution was simple: Shorten the label names. I set a restriction to 32 chars per label.

But I have also to say: I tried to reproduce the error in a small project with really, really long label names, without success. Everything works flawlessly. So it must be something else, e.g. two or more long labels are linked to the same code line or something like this.

[lightforce6128]

I tried it again with this small program:

Code Select Expand

NOLIST
ORG #4000
label_6789_123456789_123456789_123456789:
DEFS 32
LD BC,label_6789_123456789_123456789_123456789
Open diassembly window, go to address #4000, then go forward until the 'LD BC,nnnn' instruction gets visible.
This does not trigger the error.

But if the label gets one block longer, than the error will appear.

Code Select Expand

NOLIST
ORG #4000
label_6789_123456789_123456789_123456789_123456789:
DEFS 32
LD BC,label_6789_123456789_123456789_123456789_123456789
The error does not happen on disassembly lines where the label is used as comment ("this label belongs to this line").
Instead it happens if the label is part of the disassembled source, as with the 'LD BC,nnnn' command above.

This means: Labels up to 40 characters seem to be ok, but labels with 50 characters trigger the error in disassembled lines, where the value is used (by intention or by chance, e.g. because some calculation ends up with the same value as the label).

[lightforce6128]

This is the last one that works:

Code Select Expand

NOLIST
ORG #4000
label_6789_123456789_123456789_123456789_1234567:
DEFS 32
LD BC,label_6789_123456789_123456789_123456789_1234567
This one no longer works:

Code Select Expand

NOLIST
ORG #4000
label_6789_123456789_123456789_123456789_12345678:
DEFS 32
LD BC,label_6789_123456789_123456789_123456789_12345678
So this means maximum label length (in this test scenario) is 48 characters.

[Targhan]

Do yourself a favor and use ACE-DL by Roudoudou. The user interface is a bit raw, but it's powerful.
Two features that are game-changers:
- use RASM to directly generate SNApshost, add BRK1, BRK2, etc. labels in your code and they will automatically be inserted in your snapshot as breakpoints. This is so convenient for debugging!
- Once a SNA is loaded in ACE-DL, it is "observed" by ACE-DL, so if you build it again, it is automatically reloaded, so you can make plenty of tests without having to drag'n'drop anything or click anywhere.

[NJean]

This means: Labels up to 40 characters seem to be ok, but labels with 50 characters trigger the error in disassembled lines, where the value is used (by intention or by chance, e.g. because some calculation ends up with the same value as the label).

Brilliant! 

I won't be able to check it right away, but your explanation sounds VERY promising!
(I'm relieved that the limit isn't on the number of symbols but on their length, which is easier to restrict...)

NB: the "fatal" symbol can be a little tricky to find because I get the impression that the debugger window (=disassembler) tries to replace all constants with a symbol of the same value, and it often happens that this symbol has no relation to the value actually used (except that they do have the same value, but that's a coincidence...)

By default, I will probably try to limit all my symbols to a reasonable size...

Thank you very much, you've probably just saved me a lot of time...

[Prodatron]

So this means maximum label length (in this test scenario) is 48 characters.

Thanks a lot for this finding! Glad, that you could solve the issue, this is very useful to know.

What I fear (but this is probably unfair to Richard Wilson) is that some WinAPE table has a static limit...

This is something I've always wondered about.
My current main source code contains about 5,300 labels, and that's nothing for WinApe.

So I did some tests. 65,536 labels and then 100,000 are no problem either. With 150,000 labels, it takes a bit longer after the two assembly passes have completed.
I haven't done any tests with relocatable SymbOS apps, which require four passes; perhaps that causes more stress.

With 500,000 labels, it takes so long that I've killed the WinApe task.
Since this high number of labels is absurd, I'd say WinApe has no problem with lots of labels at all 


By the way, 800 KB ASM source and such label names... I'm curious what project you're working on 

[roudoudou]

for big project and a lot of labels, code, i recommend using RASM (minutes will become milliseconds)

[NJean]

Epilogue:

Unsurprisingly, lightforce6128's explanation was correct...

I ran the lawnmower over some unreasonably long labels, and WinAPE is my best friend again.
Sorry for thinking about leaving you, WinAPE... Please forgive me!

Thank you all for your suggestions. I won't be able to follow all your excellent advice, but I was very honored by the interest that such great minds took in my little problem...



Epilogue 2:

By the way, 800 KB ASM source and such label names... I'm curious what project you're working on 

After all the fuss I've made, this curiosity seems quite legitimate...
However, at the risk of disappointing you, as I'm not sure the result will be worth it, I prefer not to announce anything for the moment. 


But if I have something to share, I promise this forum will be the first to know. In any case, don't get your hopes up too high!

And I swear I'm not secretly working on an alternative graphical Z80 multitasking Operating System!

[norecess464]

BTW, this may appear to be evil, but if you really want to run WinAPE on a modern system:
- you can still launch any programs in Windows in a "compatibility mode" (for prior Windows version). It may help, not sure about the effects on WinAPE.exe specifically.
- you can... run WinAPE inside a Windows 7 VM (Virtual Machine, cf. VirtualBox etc.) and it will work 100%.

But as mentioned above with ACE-DL etc. WinAPE is quietly dying; it was a great friend for 2 decades and a half (!!) but finally there are great replacements progressively coming.