Logging program output, in emulator or real CPC ?

[cpcitor]

Hello,

Logging is good

As I clear up the path along development, it's more and more comfortable developing in ANSI C with SDCC in cpc-dev-tool-chain: a portable toolchain for C/ASM development targetting CPC. . See also Sharing feedback on using SDCC for a non-trivial C program. .

I'm using assert a lot to sanity check my program. Assert is good because you can put a lot of assert, they are your angels taking care of you, and you can get a clean production build with no trace of them by just compiling with make NDEBUG=1.

This is an example from my current project :

Code Select Expand


        assert( this_grid->dimensions.row <= CF_MAXGRIDSIZE );
        assert( this_grid->dimensions.col <= CF_MAXGRIDSIZE );
        assert( this_grid->dimensions.row > 0 );
        assert( this_grid->dimensions.col > 0 );


Assert saved my day allowing to more quickly spot a bug in iDSK. As you can see, the pointer supposed to write on the screen was less than C000, which is not on screen. Knowing the file and line allowed to spot where the corruption was in memory thanks to detailed SDCC output then search in DSK file.

[attachimg=1]

CPC screen is small

For a simple assert on program crash, this kind of display is fine. But for logging more, it's just unusable.

Still it may be good to log more program output.

Logging through a serial interface, real or emulated

Usually, embedded devices log through a serial RS232 connection.

If there's one common interface to program a RS232 on the CPC, it would be nice to use that, even in an emulator. But it looks like each hardware interface has its own style. See for example Amstrad Serial Interface - CPCWiki .

I know I can also run my program as native code with as much log as I want, but this debugs only program logic, not display routines. :-)

Else, it may make sense to just hack something simple in a emulator source code, like output a value to some i/o port and let the emulator display the result on standard output.

What do you think ?

[opqa]

If you don't mind using one emulator or another, VirtualCPC has embedded Amstrad Serial Interface emulation, it's far from perfect, but it works. You can install a generic virtual serial port software in your OS and connect VirtualCPC to it.

About the differences between different serial port interfaces, they are not so big deal, the bigger differences are in hardware initialization, which you can always program in a separate routine. After the hardware is initialized the way you transmit/receive data is practically the same.

To transmit, there is one port you must check before sending data to make sure there is free space in the transmit buffer and another port to send the data itself. For receiving, more or less the same, one port to check whether there is data available and another to retrieve it. Those ports may change from one interface to the other, and also the bits that indicate data available/ready to transmit, but the mechanism is the same for all of them so the same code with little minor changes can be used.

[Bryce]

The problem with logging from a real CPC through RS232 is that you would need a monitor program running in the background to feed the connection. This not only uses up resources, but when your program crashes, then the monitor has stopped working too. The most robust way to monitor a real CPC would be to make a hardware expansion that logs the address bus and data bus directly from the expansion port. That way it always logs what happened, you could even add "halts" for particular data / addresses if required. This hardware could be stand-alone (LCD screen output) or pass the information via RS232/USB/BT or whatever to a PC.

Bryce.

[opqa]

The problem with logging from a real CPC through RS232 is that you would need a monitor program running in the background to feed the connection. This not only uses up resources, but when your program crashes, then the monitor has stopped working too. The most robust way to monitor a real CPC would be to make a hardware expansion that logs the address bus and data bus directly from the expansion port. That way it always logs what happened, you could even add "halts" for particular data / addresses if required. This hardware could be stand-alone (LCD screen output) or pass the information via RS232/USB/BT or whatever to a PC.

Bryce.

But you are talking about a completely different animal, what you propose is low-level debugging, useful for "small" assembler routines. What cpcitor talks about is using standard debugging techniques within the same C source. Like assertions and/or maybe exceptions. The idea of those techniques is precisely to avoid program crashes by detecting unusual/forbidden states at execution time and notify them throwing an error message before they cause a program crash. This of course take resources, but they can be used only during the debugging phase and turned off when compiling the final version.

[Bryce]

Ah, ok. As he mentioned "real CPCs" and RS232 interfaces, I assumed it was for "watching" the code while it's running on a real CPC.

Bryce.

[cpcitor]

Thank you for your insightful feedback, yes there are two different styles, all this is interesting.

I'm somehow used to platforms where you just OUT some byte at some port and hardware takes care about the rest.
Does it mean that most RS232 adapters work only if you keep firmware alive with interruptions, etc ?

For real CPC, simplest and less hardware-dependent might be to keep a debug build of the program, or even a simple test suite for portability (which is somehow a third animal).

I did not know VirtualCPC. I currently use Kevin's Arnold emulator on Linux because it's portable and open source, though some others are, too.

It looks like the simplest is some emulator-specific modification. For example, the CPC writing a byte at port &FEFE would cause the emulator to add the character to a log file on the host filesystem. Why &FEFE ? Because of Emulator IDs - CPCWiki

Kevin, what do you think ?

[Bryce]

Yes, real CPC RS232 expansions are usually nothing more than an address decoder and some level switching circuitry. If you don't send it info it just sits there passively doing nothing.

Bryce.

[opqa]

Does it mean that most RS232 adapters work only if you keep firmware alive with interruptions, etc ?

Not at all, I don't know where you did take this impression. To the contrary, most RS232 adapters make no use of interrupts at all, and even for those which can use them it is usually an optional feature disabled by default.

I'm somehow used to platforms where you just OUT some byte at some port and hardware takes care about the rest.

Well, if I remember correctly, you can do this, for instance, with the VirtualCPC's emulated serial port. As long as it isn't a real RS232 connection, there is no need to initialize the "hardware", and even no need to check the "Tx Ready" bit as long as it isn't emulated (for this reason this emulation was not 100% compatible with existing software), the data is transmitted instantaneously and whatever is connected to the emulated serial port must take care of it. For that particular serial interface it was the port &FADC.

But, for a real RS232 connection, this can't be so easy. First, you must indicate the hardware someway which transmission speed you're going to use, number of bits, parity, flow control, stop bit(s), and all this stuff. Usually something like 9600 8N1 is quite standard and recognized by many hardware like Serial-Bluetooth or Serial-USB modules, although this hardware might also need to be configured to match the same values as in the CPC (like in the case of Serial-Bluetooth modules).

Once initialized, and depending on the buffer size and flow rate of the data you are going to transmit, you might need to check the Tx Ready flag before actually transmitting. This is because even at high serial speeds (like 115200bps), the CPC is able to send data much faster than what the connection can transmit. So, if you send and error message that doesn't fit in the transmission buffer of the serial interface you're using, you'll lose characters. Also, this may happen in case you are using low speeds and transmitting log messages continuously at a fast rate.
This is a serial connection issue and no hardware can take care of it for you, unless it has a huge transmission buffer that never overflows. IIRC the miniBooster has 256 Bytes, which is not bad at all, but it might be filled up in the above cases if the UDR empty flag is not checked before transmitting every byte.

EDIT: Just checked and the 255 bytes buffer of the CPC Booster is for reception only, I don't have any idea of what the Tx buffer size might be, but I believe it could be just 1 byte, so checking the UDR empty bit flag (for full duplex transmissions) would be mandatory.
http://www.cpcwiki.eu/index.php/Programming:CPC_Booster

[cpcitor]

Thanks for the explanation. That sounds closer to what I expected (I'm still using serial ports in my day job, though at a higher level generally -- there are even chips that plug to serial port wire and on the other side to an Ethernet network to accept connections where the characters are exchanges, that could be an easy way to connect a CPC to Ethernet).

Depending on the need (not confirmed so far, -- that is nothing yet), I guess I'd start with the emulator integration. Assert will probably still write on the screen, while regular log (in debug builds) would go to the log file.

[gerald]

What about using the parallel port ?
Some emulator allow to get this to a file, and it should be easy to make a dongle to collect it from a real CPC to USB or serial.

[opqa]

What about using the parallel port ?
Some emulator allow to get this to a file, and it should be easy to make a dongle to collect it from a real CPC to USB or serial.

Sounds like a great idea, a simple and cheap Arduino board might do the trick. It has all what is needed.

[cpcitor]

What about using the parallel port ?
Some emulator allow to get this to a file, and it should be easy to make a dongle to collect it from a real CPC to USB or serial.

Which emulators do that ? I couldn't find this in Arnoldemu.

[Octoate]

Which emulators do that ? I couldn't find this in Arnoldemu.

WinApe for example (Settings-Other-Printer), WinCPC AFAIK too (unable to check it on my Win8 system) and JavaCPC contains a printer console, where you can directly see the output. In my opinion this is a great idea and, like opqa already mentioned, it should be easily possible to connect an Arduino with display to the printer port (or just to read the data from it).

[arnoldemu]

under wip arnold it's here:

Settings->Devices->Printer->File->Set File...