Author Topic: WinAPE enhancements  (Read 21596 times)

0 Members and 1 Guest are viewing this topic.

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 390
  • Likes Given: 60
WinAPE enhancements
« on: 11:09, 22 March 16 »
For the next version of WinAPE I have a number of things on the list, but I'd like to know which are the most important for most people.

Currently, in order of importance (to me) are:

1. Networking - (there is currently no actual working hardware that I can emulate). I was planning on emulating the W5100 or something similar and putting it on an arbitrary port, but it doesn't appear anyone can get an actual interface working with that chip. These are other possibilities, but I may resort to creating my own custom socket implementation using a particular set of I/O ports.

2. Project files - A way to group WinAPE assembler files (and maybe other resources) together and have some form of build script which would allow such things as calling external programs during the build.

3. Inter-Process communications channels - A way to allow other programs control over WinAPE with a scripting engine to allow running of scripts. This could be achieved under Windows using either of Memory-Mapped Files or WM_COPYDATA messages both ways.

4. Speech emulation (SSA-1). Actual emulation of the phoneme ROM and synthesis module rather than simply playing a set of WAV files.

5. Improvements to Plus emulation, including emulating soft-scroll in officially unsupported modes (eg. MODE 0 with horizontal SS of 15), more accurate raster interrupt and DMA emulation, and more accurate ASIC RAM read/write masks and values. I think most of it is fairly accurate, but people keep posting how wonderful another emulator is that hardly anybody can actually use.

6. Anything else that people would really like to see.

Offline Joseman

  • 6128 Plus
  • ******
  • Posts: 778
  • Country: es
  • Liked: 628
  • Likes Given: 429
Re: WinAPE enhancements
« Reply #1 on: 11:22, 22 March 16 »
Hi

I don't know if the Simbiface II mouse is emulated but i would like that winape can support this

I can't make work Bonny Dos / Hard drive on winape, ¿is the IDE protocol 100% supported on winape?

For me is important that actual hardware that have hundreds of users, can work on emulators for coding purposes...

And for me Winape is the best emulator for coding!








Offline PhilZeVibe

  • 464 Plus
  • *****
  • Posts: 465
  • Country: fr
    • CPCBox - CPC emulator in JavaScript
  • Liked: 160
  • Likes Given: 182
Re: WinAPE enhancements
« Reply #2 on: 11:27, 22 March 16 »
@Executioner: All that sounds very good.

Another suggestion I can make is to implement access to CPC disk/tape online databases.

It's a great functionality that already exists in JavaCPC Desktop:

[attachimg=1]
Atwood's law (2007): "Any application that can be written in JavaScript, will eventually be written in JavaScript."

Offline reidrac

  • Supporter
  • 6128 Plus
  • *
  • Posts: 659
  • Country: gb
  • Trying to gamedev!
    • index.php?action=treasury
    • usebox.net
  • Liked: 1165
  • Likes Given: 694
Re: WinAPE enhancements
« Reply #3 on: 12:22, 22 March 16 »
3. Inter-Process communications channels - A way to allow other programs control over WinAPE with a scripting engine to allow running of scripts. This could be achieved under Windows using either of Memory-Mapped Files or WM_COPYDATA messages both ways.

Please take into account that a lot people currently use WinAPE in non windows systems (eg, Linux with WINE, WinAPE is probably the best emulator in that platform). It would be nice if you could run winape.exe (or a client.exe) that could send commands to and existing instance of WinAPE.

6. Anything else that people would really like to see.

I think (3) could do the trick, but what I really want is to be able to provide a DSK file from command line and automatically run specific input (eg, run"whatever.bin"; without having to use the UI). That would be really handy in the development cycle when I'm testing things.

Other than that WinAPE currently does what I need, even in Linux :)
« Last Edit: 12:30, 22 March 16 by reidrac »
Released The Return of Traxtor, Golden Tail, Magica and The Dawn of Kernel for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

Offline khaz

  • 464 Plus
  • *****
  • Posts: 490
  • Country: fr
  • Liked: 248
  • Likes Given: 68
Re: WinAPE enhancements
« Reply #4 on: 13:20, 22 March 16 »
I'd like to have the dsk editor as a separate executable please.

Offline Docent

  • CPC6128
  • ****
  • Posts: 162
  • Country: pl
  • Liked: 104
  • Likes Given: 0
Re: WinAPE enhancements
« Reply #5 on: 13:30, 22 March 16 »
For the next version of WinAPE I have a number of things on the list, but I'd like to know which are the most important for most people.

Currently, in order of importance (to me) are:

here're my favorites list  (6 position on your importance list :)
1.
- fix crash related to handling of directx surfaces after screen blanking/hibernation (on win7/8)
- fix "Action Unsupported" message when going full screen on win8
- fix problem with minimizing windows - minimizing all windows except the main will not minimize them to the taskbar - on win8 such window is lost for ever and cannot be bring back to screen until quitting the emulator.
- add support for 'dump' Maxam option. eg dump "filename" should dump labels to file filename.
- get rid of Maxam only compatibility and
   - extend expression enumeration to support parentheses
   - extend parser to handle new syntax for hex numbers (ie 0xff, ffh)
- assembler: out (c),0

2. project files
3. Improvements to Plus emulation
4. Inter-Process communications channels
5. Networking
6. Speech emulation
more comments below.


1. Networking - (there is currently no actual working hardware that I can emulate). I was planning on emulating the W5100 or something similar and putting it on an arbitrary port, but it doesn't appear anyone can get an actual interface working with that chip. These are other possibilities, but I may resort to creating my own custom socket implementation using a particular set of I/O ports.
Instead of emulating a chip no one have used before on cpc, I'd suggest to create a tcp/ip stack emulation/bridge by extending firmware vectors.
There are a number of empty space that could be filled with additional vectors, for example between
bdf7-be40 - 24 entries
baea-bb00 - 7 entries

The basic set of such Network Pack would require 17 entries
NET SOCKET, NET BIND, NET CONNECT, NET LISTEN, NET ACCEPT, NET SEND, NET SENDTO, NET RECV,  NET RECVFROM,
NET CLOSE, NET SHUTDOWN, NET SELECT,  NET GETSOCKOPT, NET SETSOCKOPT, NET GETSOCKNAME, NET SENDMSG, NET RECVMSG

These functions can be almost directly mapped to winsock calls via a specially marked cpc ROM. The ROM would be detected by WinAPE and treated as a bridge between cpc and windows.
 A program on cpc would call these vectors, the ROM would call winsock through WinAPE etc. With such set of functions porting of network enabled applications would be pretty easy.
This approach would also set a comon api standard for networking and in the future (if someone will ever build an ethernet interface for cpc) will give some sort of basis for compatibility.

3. Inter-Process communications channels - A way to allow other programs control over WinAPE with a scripting engine to allow running of scripts. This could be achieved under Windows using either of Memory-Mapped Files or WM_COPYDATA messages both ways.
I would add scripting support first, for example using lua. Lua is pretty easy to integrate and there are bindings for delphi already available. Scripting could be also used for projects - the build script could be Lua script..
I wouldnt bother with memory mapped files - just use WM_COPYDATA with dw_data as a some sort of message identifier to expose selected WinAPE functionality (eg. load dsk, load snapshot, run, assemble etc).
Same functionality could be exposed to the scripting engine so WinAPE could be controlled both by a script or another application.


Offline SOS

  • Supporter
  • CPC6128
  • *
  • Posts: 288
  • Country: de
  • Identity lost
    • index.php?action=treasury
  • Liked: 185
  • Likes Given: 167
Re: WinAPE enhancements
« Reply #6 on: 14:54, 22 March 16 »
Hi,

my two wishes:
- no more crashes with "breakpoint on read", e. g.
       Org &a000
       ld hl,&3000
       ld a,(hl)
       jr &a000
  => With a "breakpoint on read" on &3000 makes winape to crash
- Albireo-Integration  :D
   (maybe it's possible, when a ch376-board is connected on the Windows-PC to usb or spi)

Thanks & Bye

Bernd
 

Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 833
  • Liked: 389
  • Likes Given: 67
Re: WinAPE enhancements
« Reply #7 on: 15:40, 22 March 16 »
For 3: The most Windows friendly way would be to expose a COM interface. It would then be drivable from pretty much any scripting language going as well as easy to interface with from "real" applications.

5) would definitely be top of my list though. Accurate Plus emulation in odd situations is always useful.

Beyond that, extending the assembler to support things like macros, namespaces and other useful gubbins would be nice, even if it was at the expense of direct Maxam compatability.

Offline ronaldo

  • Dev
  • 6128 Plus
  • *****
  • Posts: 593
  • Country: es
    • Fremos Blog
  • Liked: 794
  • Likes Given: 778
Re: WinAPE enhancements
« Reply #8 on: 17:55, 22 March 16 »
I think (3) could do the trick, but what I really want is to be able to provide a DSK file from command line and automatically run specific input (eg, run"whatever.bin"; without having to use the UI).
WinAPE already does almost that. You can load DSKs and NOI symbol files from the command line and tell WinAPE to autorun the main file. cpct_winape script automatizes all for you under Linux or MacOS X. You can use it if you like or have a look at the code and adapt it to your needs if you prefer.

Anyways, I also think that running a custom command from the command line is a good idea. Under some circumstances, it would be much comfortable.

Offline reidrac

  • Supporter
  • 6128 Plus
  • *
  • Posts: 659
  • Country: gb
  • Trying to gamedev!
    • index.php?action=treasury
    • usebox.net
  • Liked: 1165
  • Likes Given: 694
Re: WinAPE enhancements
« Reply #9 on: 18:24, 22 March 16 »
WinAPE already does almost that. You can load DSKs and NOI symbol files from the command line and tell WinAPE to autorun the main file. cpct_winape script automatizes all for you under Linux or MacOS X. You can use it if you like or have a look at the code and adapt it to your needs if you prefer.

Ha! well, that settles it. Never checked WinAPE help:  "/A:filename file.dsk" is all I need!

EDIT: seriously, I feel really stupid now. Thanks for the tip!
« Last Edit: 18:37, 22 March 16 by reidrac »
Released The Return of Traxtor, Golden Tail, Magica and The Dawn of Kernel for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

Offline Arnaud

  • Supporter
  • 464 Plus
  • *
  • Posts: 484
  • Country: fr
  • Liked: 398
  • Likes Given: 762
Re: WinAPE enhancements
« Reply #10 on: 20:17, 22 March 16 »
Drag and Drop Autorun like CPCE95.

Very useful to quickly start emulation.

Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 833
  • Liked: 389
  • Likes Given: 67
Re: WinAPE enhancements
« Reply #11 on: 20:23, 22 March 16 »
Anyways, I also think that running a custom command from the command line is a good idea. Under some circumstances, it would be much comfortable.
As a strategy it tends not to play well with multiple instances running though (which is a handy thing to have during development) and also tends towards having to do a lot of parsing of output, which is decidedly less than ideal for more complex interactions with structured data.

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 390
  • Likes Given: 60
Re: WinAPE enhancements
« Reply #12 on: 22:55, 22 March 16 »
- no more crashes with "breakpoint on read", e. g.
       Org &a000
       ld hl,&3000
       ld a,(hl)
       jr &a000
  => With a "breakpoint on read" on &3000 makes winape to crash

Hi Bernd,

I can't replicate this, works perfectly for me. Did you have a condition on the breakpoint?

Offline Executioner

  • Supporter
  • 6128 Plus
  • *
  • Posts: 783
  • Country: au
  • WinAPE Developer
    • WinAPE
  • Liked: 390
  • Likes Given: 60
Re: WinAPE enhancements
« Reply #13 on: 23:32, 22 March 16 »
1.
- fix crash related to handling of directx surfaces after screen blanking/hibernation (on win7/8)

I'll try and replicate this. The DirectX code does try to recreate the surface, but oviously fails in some cases.

Quote
- fix "Action Unsupported" message when going full screen on win8

Is this because your graphics card doesn't support the required screen mode? I'm looking at adding a combo box to select full screen resolution and enable scaling (with or without maintaining aspect ratio).

Quote
- fix problem with minimizing windows - minimizing all windows except the main will not minimize them to the taskbar - on win8 such window is lost for ever and cannot be bring back to screen until quitting the emulator.

I've never used Windows 8. I think it's Microsofts worst OS ever. This doesn't happen in Windows 7 on my PC. Does the same happen on Windows 10?

Quote
- add support for 'dump' Maxam option. eg dump "filename" should dump labels to file filename.

Shouldn't be too hard.

Quote
- get rid of Maxam only compatibility and
   - extend expression enumeration to support parentheses
   - extend parser to handle new syntax for hex numbers (ie 0xff, ffh)
- assembler: out (c),0

- I could make strict Maxam compatibility an option when I have project files.

- Adding parenthesis shouldn't be too hard even without that, however, parenthesis are used to change the meaning of mnemonics (eg. ld a,(#40) is not the same as ld a,#40), so how do you suggest the assembler recognise the difference iy you wanted to do something like ld a,(x + w) * 4? I suppose the rule could be that the expression starts with '(' and ends with ')'. Could be a difficult change to make.

- Are there other assemblers that accept C style hex numbers? I suppose it can be done easily enough. I've only seen the 'h' format used when prefixed with a digit (eg. 0ffh) as that format would restrict symbol names somewhat, eg. You couldn't have a label named "each".

Quote
2. project files

The idea is to have all included files listed in the project file so I can create a Tree view, and have settings specific to the project.

Quote
3. Improvements to Plus emulation

Here is where I may need more input from people who just send messages saying "WinAPE isn't accurate", usually with no other information as to why, and having done no research themselves to find out what is wrong.

Quote
Instead of emulating a chip no one have used before on cpc, I'd suggest to create a tcp/ip stack emulation/bridge by extending firmware vectors.

I sort of like this idea, but it has one major drawback: Most software that's going to be using networking probably won't use any firmware vectors, or firmware at all for that matter. It'd probably be better to create an I/O device which has these functions, then create a ROM image which gives a firmware vector access to the I/O routines. I'd probably go for a single vector (eg. BDF7) with either a stack based command ID or use a register for the ID. eg.

CALL #BDF7:DB NET_SOCKET

or

LD A,NET_SOCKET
CALL #BDF7

This provides the same compatibility, but the underlying functions could actually use something like:

LD BC,NET_PORT
LD A,NET_SOCKET
OUT (C),A

making them available to the likes of FuturOS and SymbOS (which is actually the main reason I'm providing it).

Quote
I would add scripting support first, for example using lua. Lua is pretty easy to integrate and there are bindings for delphi already available. Scripting could be also used for projects - the build script could be Lua script..

Thanks for the hint, I've never heard of LUA before but I'll look into it.

Quote
I wouldnt bother with memory mapped files - just use WM_COPYDATA with dw_data as a some sort of message identifier to expose selected WinAPE functionality (eg. load dsk, load snapshot, run, assemble etc).

WM_COPYDATA has a fundamental flaw in that you can't return Strings. Although, there are very few cases where this is required, I'd like to support it. Perhaps WinAPE can post a WM_COPYDATA message back to the source handle.

Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 833
  • Liked: 389
  • Likes Given: 67
Re: WinAPE enhancements
« Reply #14 on: 01:50, 23 March 16 »
I've never used Windows 8. I think it's Microsofts worst OS ever. This doesn't happen in Windows 7 on my PC. Does the same happen on Windows 10?

On both Windows 8 and 10 for me, at least, they minimize to tiny little strips (just large enough to contain the icon, min, max and close buttons) and sit just above the Task Bar.

Quote
- Adding parenthesis shouldn't be too hard even without that, however, parenthesis are used to change the meaning of mnemonics (eg. ld a,(#40) is not the same as ld a,#40), so how do you suggest the assembler recognise the difference iy you wanted to do something like ld a,(x + w) * 4? I suppose the rule could be that the expression starts with '(' and ends with ')'. Could be a difficult change to make.

It does introduce ambiguities. Could just get around it by using [ ] for expressions instead, maybe? ld a, [x + w] * 4 would be entirely obvious, easier to parse and still flexible enough to accommodate making expression order clearer.

Offline Fessor

  • CPC6128
  • ****
  • Posts: 189
  • Country: de
  • Liked: 149
  • Likes Given: 40
Re: WinAPE enhancements
« Reply #15 on: 02:34, 23 March 16 »
I wish better Linux/Wine compatibility.
- German Keyboard is not recognized and it is not possible to map the keys to CPC-Keys, because they aren't listed in the Listboxes
- Redraw-Problems at the Editor of the Assembler
- Redraw-Problems at the Icons of the Main-Window
(Maybe all this Problems are Direct-X-related(?), because WinCPC, written also in Delphi, didn't have these Problems.)


Offline Grim

  • CPC6128
  • ****
  • Posts: 202
  • Country: gp
  • La pak ba, bèf ka pasé
    • THERE IS NO GAME
  • Liked: 133
  • Likes Given: 67
Re: WinAPE enhancements
« Reply #16 on: 03:44, 23 March 16 »
6. Anything else that people would really like to see.
I really would like WinAPE to be controllable telepathically. I really do :)

I would add scripting support first, for example using lua.


Offline greatxerox

  • CPC464
  • **
  • Posts: 32
  • Country: fr
    • EMU-FRANCE / Amstrad.EU / Rommanager.com
  • Liked: 5
  • Likes Given: 6
Re: WinAPE enhancements
« Reply #17 on: 04:23, 23 March 16 »
hi


i'd like ZIP support ! to launch .dsk inside .zip archives


and connect to databases like on javaCPC

Offline Docent

  • CPC6128
  • ****
  • Posts: 162
  • Country: pl
  • Liked: 104
  • Likes Given: 0
Re: WinAPE enhancements
« Reply #18 on: 05:40, 23 March 16 »
I'll try and replicate this. The DirectX code does try to recreate the surface, but oviously fails in some cases.
Yes, this is probably it - when WinAPE is minimized, it crashes much less frequently.
Is this because your graphics card doesn't support the required screen mode? I'm looking at adding a combo box to select full screen resolution and enable scaling (with or without maintaining aspect ratio).
I don't know what is the required resolution, I use Lenovo W520 laptop with NVidia Quadro 1000M chipset and windows 8.1 Enterprise. I run it in 1920x1080 32bit but the chipset also supports other, lower resolutions, however it may not support the WinAPE fullscreen resolution.
An option to select the resolution for fullscreen would be great.
 
I've never used Windows 8. I think it's Microsofts worst OS ever. This doesn't happen in Windows 7 on my PC. Does the same happen on Windows 10?

This is rather WinAPE issue than windows issue - I changed the desktop size to be smaller than 1920x1080 (1600x700) and minimized windows started to appear just over the taskbar.
- Adding parenthesis shouldn't be too hard even without that, however, parenthesis are used to change the meaning of mnemonics (eg. ld a,(#40) is not the same as ld a,#40), so how do you suggest the assembler recognise the difference iy you wanted to do something like ld a,(x + w) * 4? I suppose the rule could be that the expression starts with '(' and ends with ')'. Could be a difficult change to make.
one approach could be to use # - for example ld a, #(x+w)*4 would mean ld a,#expression while ld a, (x+w) would mean ld a, (#expression). Another approach could be that if an expression contains additional params outside the parenthesis, it will be treated as ld a,#expression otherwise it will be ld a,(expression)
The first is probably better...
- Are there other assemblers that accept C style hex numbers? I suppose it can be done easily enough. I've only seen the 'h' format used when prefixed with a digit (eg. 0ffh) as that format would restrict symbol names somewhat, eg. You couldn't have a label named "each".
There are a couple of standards, for example:
- a number in the Intel format (0nnnnH - no problem with 'each' label due to leading '0')
- a number in Motorola format ($nnnn)
- a number in AT&T format (C language - 0xnnnn)
Pasmo assembler supports all these formats.
I sort of like this idea, but it has one major drawback: Most software that's going to be using networking probably won't use any firmware vectors, or firmware at all for that matter. It'd probably be better to create an I/O device which has these functions, then create a ROM image which gives a firmware vector access to the I/O routines. I'd probably go for a single vector (eg. BDF7) with either a stack based command ID or use a register for the ID. eg.

CALL #BDF7:DB NET_SOCKET

or

LD A,NET_SOCKET
CALL #BDF7
I think that having separate vector for each function instead of just one vector for all would be better:
- no need to use  A  for function id - you save one reg and these functions have up to 6 params, so it is essential to have as much free regs as possible.
- code is simpler, no need for checking the id or jump table.
- patching is easier, ech vector can be patched separately
- its more in the style of original firmware :)

ROM could have a jump table at the beginning and will setup firmware vectors during normal init. The jumptable in ROM can be used by nonsystem software like symbos while system friendly programs will go through firmware vectors. Basic could be also extended with new commands.

A simple smtp client could be implemented in a few lines of code - the example below would connect to the server and start conversation with the smtp server.
ld a, AF_INET
ld b, SOCK_STREAM
ld c, IPPROTO_TCP
call NET_SOCKET
or a
jr z, error
ld a, (socket)
ld hl, sockadrr_in
call NET_CONNECT
or a
jr m, error

ld a, (socket)
ld hl, helo
ld de, ok-helo
ld bc, flags
call NET_SEND

ld a, (socket)
ld hl, inbuf
ld de, inbufend-inbuf
ld bc, flags
call NET_RECV
....
error:
ld a,(socket)
call NET_CLOSE
ret

// struct sockaddr_in:
sockaddr_in:
db AF_NET;family
dw 25   ;port
dw 0001   ;sin_addr_lo
dw 007f   ; sin_addr_hi

helo:
db "HELO",13
ok:
db "OK",0
inbuf
ds 10,0
inbufend
 
Thanks for the hint, I've never heard of LUA before but I'll look into it.
Its well worth to look into - its one of the fastest scripting languages (especially luajit) and quite popular (read: tested :)
WM_COPYDATA has a fundamental flaw in that you can't return Strings. Although, there are very few cases where this is required, I'd like to support it. Perhaps WinAPE can post a WM_COPYDATA message back to the source handle.
If you need to send back strings I afraid that there is no other option than sending back WM_COPYDATA. Unfortunately this message doesn't provide any information about the sender, so you'll need an additional message from the sender with its window name to send messages back. If you can stick to a number<>0 as a return value, you can use it as the return value from the message handler - officially MS requires you to return TRUE on successful processing of this message, but any value >0 should do... 
« Last Edit: 05:43, 23 March 16 by Docent »

Offline Axelay

  • 6128 Plus
  • ******
  • Posts: 545
  • Country: au
  • Liked: 345
  • Likes Given: 82
Re: WinAPE enhancements
« Reply #19 on: 14:59, 23 March 16 »



2. Project files - A way to group WinAPE assembler files (and maybe other resources) together and have some form of build script which would allow such things as calling external programs during the build.


At the moment I use several versions of WinAPE to sort of handle different projects, but even then, I'll still end up with several dozen files open in the assembler at times and it can be a bit painful getting to the right file sometimes, so if this helps streamline that then I'll like this.




4. Speech emulation (SSA-1). Actual emulation of the phoneme ROM and synthesis module rather than simply playing a set of WAV files.




Will this also include the DK'Tronics voice synth?  I've got one of those, and hope one day to support both in a game.


Any chance you'll add support for TotO's PlayCity expansion?

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
  • Liked: 1977
  • Likes Given: 4650
Re: WinAPE enhancements
« Reply #20 on: 18:07, 23 March 16 »
Would be great to see X-DDOS 2.10 running without crash on start up, maybe this includes to emulate the Dobbertin HD-20 hard drive.  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 833
  • Liked: 389
  • Likes Given: 67
Re: WinAPE enhancements
« Reply #21 on: 20:11, 23 March 16 »
Its well worth to look into - its one of the fastest scripting languages (especially luajit) and quite popular (read: tested :)

If you need to send back strings I afraid that there is no other option than sending back WM_COPYDATA. Unfortunately this message doesn't provide any information about the sender, so you'll need an additional message from the sender with its window name to send messages back. If you can stick to a number<>0 as a return value, you can use it as the return value from the message handler - officially MS requires you to return TRUE on successful processing of this message, but any value >0 should do...
The enormous downside of baking in Lua support is that then you can only automate things via Lua. Whereas exposing a COM interface (which Delphi has native support for) means you can support Lua, C++, Delphi, VB, PowerShell, VBScript.... basically anything scripting or programming language on Windows ever (since Win32 itself is about 90% COM). And then you can just pass strings as strings, without any mucking around with things like window message processing.

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.622
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 889
  • Likes Given: 1540
Re: WinAPE enhancements
« Reply #22 on: 01:46, 24 March 16 »

6. Anything else that people would really like to see.


Well I always wanted to see a Pascal like language or PLZ/SYS (the Z80 equivalent of PLM), but I would be a minority group and I'm not looking to upgrade my PC (from XP) which is 10 years old. I also retired it from the Internet a few years ago, so haven't updated to the latest Winape! :(
But the Winape I'm using, is fine when coding Hisoft Pascal programs, so I can write stuff in Notepad and use the Paste in Winape to Paste code in which works fine and if I need to Dump a program back into ASCII, just use the Printer to dump it to File, which I can edit in Notepad. The only advantage an integrated compiler would have is compile and use the necessarily library fragments to use for the program, though at the moment I haven't run into problems with the 6k Library HP attaches to final Binaries.
* Using some of the hardly used Amstrad compilers :D
* I use Firmware in my Assembly code :P
* Have interpreted some BASIC 1.1 programs for BASIC 1.0. :)

Offline SOS

  • Supporter
  • CPC6128
  • *
  • Posts: 288
  • Country: de
  • Identity lost
    • index.php?action=treasury
  • Liked: 185
  • Likes Given: 167
Re: WinAPE enhancements
« Reply #23 on: 13:00, 24 March 16 »
More Wishes ;-)
- Statistics how often one Z80-Line is hit, can see it in the debugger-window (e.g.) after the Z80-Instruction in a new column
    (Extended Request: I can see it, which are the Z80-register-values on every hit)

- Log of the Z80-Execution, e.g.:
        A000  ld b,3
        A002  inc c
        A003  djnz &A002
        A005  ld a,7
        A007  ret
  shows me:
        A000  ld b,3
        A002  inc c
        A003  djnz &A002
        A002  inc c
        A003  djnz &A002
        A002  inc c
        A003  djnz &A002
        A005  ld a,7
        A007  ret
  (Extended Request: I can see it, which are the Z80-register-values on every line, e.g. in new columns)
 
- Possible to show texts in the debugger, e.g. i wrote in Winape:
        ld b,3
    loop:
        inc c
        djnz &A002
    ThisIsATestComment:       => this one, i see in the debugger  :-)
        ld a,7
        ret
  It's possible to have the same functionality with other development-compiler?
  (i use "Phactory" with sdcc)

Offline Trebmint

  • 464 Plus
  • *****
  • Posts: 444
  • Country: zw
  • Liked: 297
  • Likes Given: 29
Re: WinAPE enhancements
« Reply #24 on: 13:01, 24 March 16 »
The Network support is 1st for me, as a Symbos coder it's a pain having to use localhost. The cool stuff a emu/network solution would open up for development would be immense