Suitable for automated benchmark execution? about z80-mbc2 HOT 59 OPEN

Hi, yes it can be done with the Iload boot mode.
This is documented for the previous version (Z80-MBC) here with SDCC: https://hackaday.io/project/19000-a-4-4ics-z80-homemade-computer-on-breadboard/log/53121-an-automated-c-language-toolchain

With the Z80-MBC2 you have to use the S190818_crt0.s file included in the SD image in the /src folder (https://cdn.hackaday.io/files/1599736844284832/SD-S220718-R240620-v1.zip).

In the same folder there is an utility (Vidit - S180818.c) written using SDCC. You can use this source file to test the automated toolchain.

from z80-mbc2.

I went to https://hackaday.io/project/19000-a-4-4ics-z80-homemade-computer-on-breadboard/log/53121-an-automated-c-language-toolchain and did not find the file section with the bat files, please can tell us where download them?
Thanks.

Alberto

from z80-mbc2.

The mentioned Files section is here: https://hackaday.io/project/19000/files

The .bat files are here: https://cdn.hackaday.io/files/19000812896000/C_batch.zip

from z80-mbc2.

Many thanks!

from z80-mbc2.

Hmm, for benchmarking, I'd also need a timer. Any recommendations? Just use a Z80-CTC like Zilog recommended back when the Z80 was new? Are they still available?

from z80-mbc2.

Hi, you can use a special IOS version that implements a 10Hz (100ms) sytem tick IRQ.
See here: https://github.com/SuperFabius/Z80-MBC2/blob/master/DEVEL/S220718-R120519_IOS-Z80-MBC2_DEVEL3.ino
You could activate the Systick IRQ generation at line 281 and write the code to use the Z80 INTR ISR to act as a timing IRQ.
But please note that if you activate by default the Systick IRQ at line 281, this IRQ will be always enabled from the beginning, so all the Z80 boot modes will not work any more (Iload too) because they do not use it.
So I can add a new Opcode (a virtual I/O device/register) to enable it from the Z80 side, so you can activate it from your custom program (or custom crt0) at the right moment.
In this way you don't need any new HW because the timer is emulated by the Atmega32.
Adding a new Opcode to do this is an easy task, so if is ok for you I can add it quickly.
So let me know...

from z80-mbc2.

...or I can just add a new Opcode to act as a start/stop timer without any IRQ, so the benchmark will not be affected by the time used to serve the Sysytick IRQ.

from z80-mbc2.

Thanks.

I've ordered a kit, and will look into it once I've assembled it.

An interrupt would be fine, though I'm not sure a 10 Hz resolution is enough. On the other boards, I use 1 kHz resolution (just using the 16-bit timer directly on STM8, via an interrupt on C8051).
I don't think the interrupt overhead would make a big difference (and after all the main purpose of the benchmarks is to compare to the same benchmark compiled using a different compiler revision, so any interrupt overhead doesn'T affect the comparison - unless we have a serious interrupt overhead regression, which is something we would want to show up in the benchmarks).

from z80-mbc2.

Hi,
I've uploaded here a custom version S220718-R120519_IOS-Z80-MBC2_DEVEL4.ino of the SW for the Atmega32 that allows to set a systick IRQ in the range of [1..255] milliseconds from the Z80 application.
To compile it with the Arduino IDE you need to put in the same directory also the others source files normally included (see here).
I've uploaded a source test file (assembler) to show how to use the new needed Opcodes (the virtual I/O commands to the Atmega32 firmware) to deal with the IRQs, as source and .hex executable file.
For any question feel free to ask.
Regards

from z80-mbc2.

Out of curiosity:

FUZIX supports the Z80-MBC2. But as a Unix, FUZIX has to implement the clock() function. I think that would also require a timer. How is is done there?

from z80-mbc2.

Using an IRQ (INTR signal) every 100ms. Anyway I haven't tested the last version of Fuzix on the Z80-MBC2.

from z80-mbc2.

After some break (got Rabbit boards to work for a similar purpose, by resurrecting OpenRabbit), I want to have another look at this. I have to admit, I didn't really do anything with the Z80-MBC2 so far (assembled it, connected the serial port, booted it, saw the messages up to "IOS: SD error 2 (NOT_READY on MOUNT operation) IOS: Check SD and press a key to repeat" and that's it. Don't have experience with avr, didn't have the hardware to change the firmware in the avr part. A few days ago, I got an Atmel-ICE basic, and hope I can use it with avrdude.

So coming back to this:

• I guess even the 10 Hz interrupt would be good enough, though a slightly higher frequency would be better.
• I'd prefer this to work without an SD card.
• What would I do with an .ino file? It looks like C source to me, so I guess I compile it with GCC for avr target then use avrdude to get the resulting firmware binary onto the Z80-MBC2?
• I guess I should try to get some "Hello, world!" or so running first, then proceed to benchmarks.
• In the end I want it fully automated: invoke a script with parameters for the compiled benchmark and the serial port used, see the output on the console (i.e. something like https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/execute_benchmark-stm8 for the STM8).
• The final goal is to use the Z80-MBC2 to get benchmark score graphs for SDCC revsisionc, to spot regressions in the SDCC z80 backend, likethis one for the SDCC stm8 port: https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/coremark-stm8-score.svg

from z80-mbc2.

To use the Z80-MBC2 with SDCC you doesn't need any SD. You have to set the "iLoad boot mode" from the system menu (press RST + USER, then release RST holding USER down until you see the menu).
In the SD image .zip file (/src) there is a S190818_crt0.s file ready for SDCC.

You can make a fully automated toolchain using Tera Term (or probably minicom) having a serial-USB adapter with the DTR line.

So as first step try to compile with SDCC a simple helloworld. You can give a look at "Vidit - S180818.c" (/src) too.
Just to have an idea how setup the toolchain give a look here (it is referred to the previous version):
https://hackaday.io/project/19000-a-4-4ics-z80-homemade-computer-on-breadboard/log/53121-an-automated-c-language-toolchain

For now you don't need to change the FW (.ino file). When you'll need the time interrupt you can use the Arduino IDE and the serial-USB adapter (with the DTR signal) as in the current FW there is already a bootloader inside the AVR MCU (but will see this later), so no need to use any external programmer.

from z80-mbc2.

Thanks. Haven't been able to use iLoad yet, as I alwas get a checksum error on the 5th line of the Intel hex file:

Enter your choice >5  Ok
IOS: Loading boot program... Done
IOS: Z80 is running from now

iLoad - Intel-Hex Loader - S200718
Waiting input stream...
:0C00000031F0FCCD0F11CD1E02C3010237
:04020000C97618FDA6
:10110F0001000078B12808110080210F11EDB0C93E
:20020400210200397EFE0A20063E0DD3013E0AD301C9DB01FEFF28FA6FC9211B00E5213425
:2002240003E5CDB004F1210C00E3213903E5CDB004F1213C0CD541BE2600020ECB411BEC50
iLoad: Checksum error!
iLoad: Load error - System halted

The line before the Checksum error varies, but it is always the same up to F1213C0.
The real .ihx file start is:

:0C00000031F0FCCD0F11CD1E02C3010237
:04020000C97618FDA6
:10110F0001000078B12808110080210F11EDB0C93E
:20020400210200397EFE0A20063E0DD3013E0AD301C9DB01FEFF28FA6FC9211B00E5213425
:2002240003E5CDB004F1210C00E3213903E5CDB004F1213C03E3CD5A04219B00E321660305

I've tried with two different USB-TTL cables, both with and without a USB hub.

My Z80-MBC2 is powered via the USB-TTL cable.

I noticed that in the post on the automated asm toolchain, you use 9600 baud, while when I bring the Z80-MBC up it apparently runs the serial interface at 115200 baud.

As terminal program I'm using gtkterm.

P.S.: Does the avr zero-initialize the board SRAM on reset?

from z80-mbc2.

When using iLoad you must use a terminal that allows to add an (about) 90ms delay at each end of line.
Tera Term and minicom allow this for sure.

I never was able to make gtkterm works as wanted to do this...

I've always used a Windows VM with Tera Term and the Z80-MBC2 (@115200 bps) to do this with a teraterm script, but if you want stay on linux you should use minicom and a little script.
Probably you'll encounter some problems due the linux EOL termination (I have always used iLoad from Windows with CRLF terminated IntelHex files), but I think that can be solved using a proper utility.

You have to create a proper script to do all the needed steps.
For now try to use minicom with somethings as:

            minicom -w  -S minicom.txt -D /dev/ttyUSB0

where minicom.txt contains somethings like:

sleep 1
! ascii-xfr -s -n -l 100 <output_intelHex_file>
sleep 1

BTW: on reset the AVR only "drives" the Z80 to load the boot program into the SRAM. The remaining SRAM is not touched.

from z80-mbc2.

Thanks. Using gtkterm --delay 90 I now get to

iLoad: Starting Address: 0000

But with both my Blink.ihx anf Ansitest.ihx apparently nothing happens afterwards.

Regarding the RAM: in C global variables are default-initialized to 0 when not explicitly initialized. Your crt0 doesn't do this (it seems to be based on an old SDCC crt0 that assumed the hardware to have zeroed the RAM). I suggest to have a look at the current SDCC crt0 for z80, which does zero-initialize all global variables that are not explicitly initialized:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/lib/z80/crt0.s

P.S.: When using minicom with the script as suggested, I instead get apparently random addresses for the starting address, such as:

iLoad: Starting Address: 0A20

or

iLoad: Starting Address: 0404

But again, nothing after.

from z80-mbc2.

I've just "resuscitated" a Z80-MBC2 board and did some test.

The first minicom.txt sleep must be 3 seconds:

sleep 3
! ascii-xfr -s -n -l 100 <output_intelHex_file>
sleep 1

It worked for me using a CRLF terminated intelHex file (made with sdcc from the Win VM)

BTW: is the zero-initialize of all global variables really really needed...?

from z80-mbc2.

Here the windows batch file to compile and generate the .hex file (I did years ago):

@echo off
rem
rem CCBIN.BAT - Compile C source file to target Z80-MBC2.
rem
rem Two output files: OUT.BIN is a binary executable
rem OUT.HEX is an Intel-hex format
rem
rem To load OUT.HEX with iLoad (after a successful compilation) use the
rem Dos batch L without any parameters
rem
rem
rem USAGE: CCBIN <source_file.c>

if .%1==. goto :error2
set scfile=%1
if not exist %scfile% goto :error1
ECHO Compiling...
sdcc -mz80 --data-loc 0x6000 %scfile% -o out.hex
if not %ERRORLEVEL%==0 goto :error3
echo No compiler errors.
copy /y out.hex load.hex > nul
echo Converting to binary...
hex2bin -p 00 out.hex
if not %ERRORLEVEL%==0 goto :error4
echo Output binary file: OUT.BIN
echo All done. Bye bye...
goto :end

:error4
echo Error converting HEX to BIN!
goto :end

:error3
echo Errors found in source file %scfile% during C compilation.
echo No binary output file.
goto :end

:error2
echo Please specify a source file!
echo.
echo CCBIN.BAT - (C Compile with BINary output)
echo Compile C source file to target Z80-MBC2 with .bin and .hex output.
echo.
echo USAGE: CCBIN ^<source_file.c^>
echo.
echo Two output files will be generated: OUT.BIN is a binary executable
echo OUT.HEX is an Intel-hex format
echo.
echo To load OUT.HEX with iLoad (after a successful compilation) use the
echo Dos batch L.BAT without any parameters
goto :end

:error1
echo Error: file %scfile% not found!

:end

from z80-mbc2.

With the 3 - second delay, I not see the same result in minicom as I saw earlier in gtkterm.
Still no user led blinking and not seing any output.
Could you attach you .ihx so I can check if my .ihx file is the problem? Your .bat apparently just uses default options (except for --data-loc 0x6000, but I've tried that one now and it didn't make a change for me).

from z80-mbc2.

This is the .hex of an ansi.c test

test.zip

I'm using:

 minicom -w  -S minicom.txt -D /dev/ttyUSB0

to load (from a shell inside the dir where the files are located).

from z80-mbc2.

Thanks. That .ihx works for me (even if I change the line endings via dos2unix).

from z80-mbc2.

Great. To be honest this one is the first time I use the Z80-MBC2 iLoad directly from linux with minicom...

Luckily I'm currently using minicom with a 68008 based board with the same script (with sLoad, an s-record version for the 68k).

from z80-mbc2.

I decided to just skip a head a bit, and found that easier, as I got a step further:

• I no longer use the custom crt0; the one that comes with SDCC apparently works just fine (so there's also no worries about zeroing global variables now)
• I just reimplemented the putchar /getchar in C, and put that at the top of Blink.c (SDCC now uses the types mandated by the C standard for those 2 functions):

int putchar (int c)
{
    Serial = 0x1;
    User = c;
    return(c);
}

int getchar (void)
{
    return(Serial);
}

• So now I see output:

iLoad: Starting Address: 0000


Hello Folk!

Just some counts...

I=0
I=1
I=2
I=3
I=4
I=5
I=6
I=7
I=8
I=9
I=10

Press USER key to continue...

• My current problem: Nothing happens when I press the User key (though for the benchmarking I want to do in the end, that is not an issue).

from z80-mbc2.

That is not clear o me...

int putchar (int c)
{
Serial = 0x1;
User = c;
return(c);
}

int getchar (void)
{
return(Serial);
}

Where is the assembler part to set the needed opcode to IOS to tx a char to the serial...?
What are Serial and User?

I mean something like this:

// Z80-MBC2 I/O ports definition
__sfr __at 0x00 EXEC_OPCODE;
__sfr __at 0x01 STORE_OPCODE;

from z80-mbc2.

There is no assembler part. Your Blink.c already has

// Z80-MBC I/O ports definition
__sfr __at 0x00 User;                       // Define USER led / USER Key port
__sfr __at 0x01 Serial;                     // Define Serial Tx/Rx port

from z80-mbc2.

ahhh... you are using this old demo...
Blink.c.zip

from z80-mbc2.

...but this one was for the previous Z80-MBC board, not for the Z80-MBC2 board...
This explains why user key doesn't work for you...
Now is late... I'll do an updated version for the Z80-MBC2...

from z80-mbc2.

Thanks. So essentially everything is working as it should, and that User key thing was just MBC vs. MBC2.

from z80-mbc2.

Yes.. I have to check but i think this is the cause... it was more than 4 yrs ago...

from z80-mbc2.

So far it works, well, e.g. Drhystone self-check passes, so the next step would be to properly implement clock() to actually measure passing time:

iLoad: Starting Address: 0000


Dhrystone Benchmark, Version 2.1 (Language: C)

Program compiled with 'register' attribute

Please give the number of runs through the benchmark: 
Execution starts, 25000 runs through Dhrystone
Execution ends

Final values of the variables used in the benchmark:

Int_Glob:            5
        should be:   5
Bool_Glob:           1
        should be:   1
Ch_1_Glob:           A
        should be:   A
Ch_2_Glob:           B
        should be:   B
Arr_1_Glob[8]:       7
        should be:   7
Arr_2_Glob[8][7]:    25010
        should be:   Number_Of_Runs + 10
Ptr_Glob->
  Ptr_Comp:          -27638
        should be:   (implementation-dependent)
  Discr:             0
        should be:   0
  Enum_Comp:         2
        should be:   2
  Int_Comp:          17
        should be:   17
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Next_Ptr_Glob->
  Ptr_Comp:          -27638
        should be:   (implementation-dependent), same as above
  Discr:             0
        should be:   0
  Enum_Comp:         1
        should be:   1
  Int_Comp:          18
        should be:   18
  Str_Comp:          DHRYSTONE PROGRAM, SOME STRING
        should be:   DHRYSTONE PROGRAM, SOME STRING
Int_1_Loc:           5
        should be:   5
Int_2_Loc:           13
        should be:   13
Int_3_Loc:           7
        should be:   7
Enum_Loc:            1
        should be:   1
Str_1_Loc:           DHRYSTONE PROGRAM, 1'ST STRING
        should be:   DHRYSTONE PROGRAM, 1'ST STRING
Str_2_Loc:           DHRYSTONE PROGRAM, 2'ND STRING
        should be:   DHRYSTONE PROGRAM, 2'ND STRING

Measured time too small to obtain meaningful results
Please increase number of runs

from z80-mbc2.

Glad that is running as expected...
I've attached here the Blink demo working for the Z80-MBC2.

Blink_MBC2.zip

Next step is flashing the new FW to allow the systick IRQ generation.

First you have to install Arduino IDE and then inside Arduino IDE install the "core" for the Atmega32A.

To install the needed core (MightyCore) follow the steps here:
https://github.com/MCUdude/MightyCore#how-to-install

When all done you will be ready to flash the new FW.

BTW: I've tried to make an ISR using SDCC, but in resulting generated code (checked with a disassembler) there isn't any trace of the JP _ISR at the wanted address (vector table) 0x0038 (or any other similar address) that should correspond to the vector 7 (it is a my "guess" as in the SDCC manual there isn't absolutely nothing explaining the relation between the number inside the __interrupt (x) parameter and the real address), so the final result is pretty useless.

The SDCC manual says at par. 3.8.1:
.... _The optional number following the "_interrupt(x)" keyword is the interrupt number this routine will service. When
present, the compiler will insert a call to this routine in the interrupt vector table for the interrupt number specified...

But there isn't any JP ISR at the expected address (vector table) and changing the vector number doesn't seem to have any effect.

Am I missing something...?

from z80-mbc2.

Just found the answer myself at par. 3.8.4:

The Z80 uses several different methods for determining the correct interrupt vector depending on the hardware
implementation. Therefore, SDCC does not attempt to generate an interrupt vector table.

So probably I've to tweak the crt0.S for that...

from z80-mbc2.

So I did actually install the Arduino IDE and that MightyCore thing, and at Tools -> Board selected "ATmega32", but there is apparently a header missing:

Arduino: 1.8.13 (Linux), Board: "ATmega32, Yes (UART0), EEPROM retained, Standard pinout, BOD 2.7V, LTO disabled, External 16 MHz"











Warning: platform.txt from core 'MightyCore' contains deprecated compiler.path={runtime.tools.avr-gcc.path}/bin/, automatically converted to compiler.path=/usr/bin/. Consider upgrading this core.
S220718-R120519_IOS-Z80-MBC2_DEVEL4:192:97: fatal error: PetitFS.h: No such file or directory
compilation terminated.
exit status 1
PetitFS.h: No such file or directory


This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

from z80-mbc2.

Did you install https://github.com/greiman/PetitFS?

from z80-mbc2.

I've attached all the needed files. Unzip it retaining the folder name and double click the .ino inside (do not use the "vanilla" PetitFS repository as I've made changes on the configuration of PetitFS).

S220718-R120519_IOS-Z80-MBC2_DEVEL4.zip

Here the setting for Arduino IDE:

Here a test program (assembler src + hex) to check that IRQ is running:

IRQ_test.zip

NOTE: For your purpose the shared IRQ scheme used in the assembler test program is an overkill (and it requires that all the IOS interactions must be treated as an atomic operation. See the assembler test program).
To simplify I suggest to enable only the Systick IRQ:

           ;
           ; IOS S220718-R120519_DEVEL4: Set Systick time (IOS)
           ;
           LD       A,SETTICK_opc   ; A = SETTICK Opcode
           OUT      (StorOpc_port),A; Write the Opcode to IOS
           LD       A, TICKTIME     ; Set the Sysytick time
           OUT      (ExecWr_port),A ; Write it to the IOS EXECUTE_WRITE_OPCODE port
           ;
           ; IOS S220718-R120519_DEVEL4: Enable the Systick IRQ only (IOS)
           ;
           LD       A,SETIRQ_opc    ; A = SETIRQ Opcode
           OUT      (StorOpc_port),A; Write the Opcode to IOS
           LD       A, 0x02         ; Enable the Sysytick IRQ only
           OUT      (ExecWr_port),A ; Write it to the IOS EXECUTE_WRITE_OPCODE port
           ;
           ; Enable IRQ on the Z80 CPU (Z80 CPU)
           ;
           IM        1              ; Enable Z80 IRQ mode 1
           EI                       ; Systick IRQ is enabled and active from now!

This way every TICKTIME milliseconds ([1..255]) an IRQ to address 0x0038 will be generated, and inside your ISR you have just to increment a long long unsigned counter and then return from the ISR (do not place any IOS interaction inside the ISR or will interfere with IOS interactions inside the normal program, unless you treat all them as an atomic operation).

Of course when reading the value from inside the program you have to treat that operation as atomic (disabling IRQ during the read/copy), but you already know that...

This way you will have something similar to the Arduino's millis() function.

IMPORTANT!!!:
Remember that iLoad takes the first address of the Intel Hex stream as the starting address for the execution.

from z80-mbc2.

Regarding the RAM: in C global variables are default-initialized to 0 when not explicitly initialized. Your crt0 doesn't do this (it seems to be based on an old SDCC crt0 that assumed the hardware to have zeroed the RAM). I suggest to have a look at the current SDCC crt0 for z80, which does zero-initialize all global variables that are not explicitly initialized:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/lib/z80/crt0.s

BTW: That file (crt0.s) cannot be compiled as the .globl definitions are all missing... This is the same issue I found more the 4yrs ago...

from z80-mbc2.

Regarding the RAM: in C global variables are default-initialized to 0 when not explicitly initialized. Your crt0 doesn't do this (it seems to be based on an old SDCC crt0 that assumed the hardware to have zeroed the RAM). I suggest to have a look at the current SDCC crt0 for z80, which does zero-initialize all global variables that are not explicitly initialized:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/lib/z80/crt0.s

BTW: That file (crt0.s) cannot be compiled as the .globl definitions are all missing... This is the same issue I found more the 4yrs ago...

sdasz80 -plosgff should assemble it (as it makes some things .globl by default).

from z80-mbc2.

I've attached all the needed files. Unzip it retaining the folder name and double click the .ino inside (do not use the "vanilla" PetitFS repository as I've made changes on the configuration of PetitFS).

Thanks. That seems to get me a step further, as I now see two hex files having been generated: S220718-R120519_IOS-Z80-MBC2_DEVEL4.ino_atmega32_16000000L.hex and S220718-R120519_IOS-Z80-MBC2_DEVEL4.ino.with_bootloader_atmega32_16000000L.hex

So I guess the next step is to get one of them somehow onto that avr on the board. I've tried with an Atmel-ICE basic connected to J3, and the board connected to +5V/GND via J2.
When I try

avrdude -p atmega32 -c atmelice

I see some activity on the LEDs (maybe a reboot?), but get this output from avrdude:

avrdude: bad response to AVR sign-on command: 0xa0
avrdude: retrying with external reset applied
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: retrying with external reset applied
avrdude: JTAGEN fuse disabled?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.

from z80-mbc2.

I suggest you to use Arduino IDE to upload the compiled "sketch" as it is the easiest way to do that.

Using a "normal" programmer you have to use the S220718-R120519_IOS-Z80-MBC2_DEVEL4.ino.with_bootloader_atmega32_16000000L.hex file (to retain the bootloader) and manually specify the needed Fuse bits into your programming SW (Fuse bits: High Byte 0xD6, Low Byte 0xAF, Lock Byte 0xCF).

BTW: as far as I know it looks like you are trying to program the MCU with JTAG instead with ICP (JTAG is already disabled in your preprogrammed MCU as it conflicts with other functions).

from z80-mbc2.

I was just about to reply to you "I've already tried that, I just get the same error text in the arduino error output window as when I invoke avrdude manually". The I noticed there is a "verbose output during upload" option in preferences, and thought I just might try it to see if I get any useful information out of it (possibly to post it here).
But when I tried to upload with verbose output enabled, it just worked!

from z80-mbc2.

Good! May be a bad contact somewhere or some type of conflict on the serial port...

Now the step is try to run the IRQ_test.zip (inside the zip there is a ready to run .HEX file to use with iLoad).

from z80-mbc2.

Thanks. The IRQ_test.zip works for me, but even the very simple attached C program simpletest.tar.gz does not.

In particular, the user led never lights up. I.e. it hangs from the moment I try to enable interrupts. When I remove the "ei", the LED does light up.

P.S.: I now wonder if maybe the

                LD       A,SYSIRQ_opc    ; A = SYSIRQ Opcode
                OUT      (StorOpc_port),A; Write the Opcode to IOS
                IN       A,(ExecRd_port) ; Read the SYSIRQ status byte in A

in the IRQ_test.zip example is required to signal to IOS that the IRQ is being handled (i.e. not just to know the reason for the IRQ)?

Some progress: Simple example apparently works if I put ei / di around the code that turn on the user led. Wonder why that would make a difference even when the interrupt routine does not do any I/O.
P.P.S.: But it only work for switching on the usee LED. When I try to output something to the serial port after switching on interrupts, I don't receive it (even with putchar() having ei / di around the I/O).
P.P.P.S.: The difference between the LED and serial stuff was timing: After enabling the interrupts, I can get a quick putchar('X') through, but apparently not a second. Maybe there is a bit of time until the first interrupt hits, but once it does something goes wrong? Even when I replace the interrupt handler by just a simple ei/reti directly in crt0.s.
P.P.P.P.S.: Using di/ei around all i/o outside of interrupt handler plus also having ld a, #0x89 out (0x01), a in a, (0x00) in the handler, I now do get further.
P.P.P.P.P.S: Dhrystone, compiled with current SDCC, default options: 539 Dhrystones / s. Looks quite good for a 80 MHz Z80 to me. For comparison, a 44.2 MHz Rabbit 3000A gets about 4700 Dhrystones / s.

from z80-mbc2.

Hi, I've just checked what the SYSIRQ Opcode does on the source (S220718-R120519_IOS-Z80-MBC2_DEVEL4.ino) and found this interesting note I wrote (@ line 1641):

  // NOTE 3: The INT_ signal is always reset (set to HIGH) after this I/O operation, so you have to call it
             always from inside the ISR (on the Z80 side) before to re-enable the Z80 IRQ again.

I completely forgot that...

So you have to call this Opcode inside the ISR also if you don't need to check which one IRQ was triggered (as in your case using only the systick), because calling SYSIRQ the INT signal is cleared.

If you don't do that the INT signal remains fixed to active (low level) and the ISR is permanently called (as you know the INT signal is "level triggered" and not "edge triggered" as NMI).

Given that, at this point you must "surround" any I/O sequence with "di/ei" to avoid that a triggered IRQ could "break" a pending "Opcode_Store/Opcode_Execute" sequence.

BTW: If you can, just for curiosity, I'd like to see your crt0 and Dhrystone.c implementation, as up to now I never used IRQ with SDCC.

from z80-mbc2.

Dhrystone including the crt0 is here:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/dhrystone-z80/

from z80-mbc2.

Thanks!!

from z80-mbc2.

I now have some nice looking code size graphs for stdcbench, Dhrystone and Whetstone, that corresond to benchmark versions that actually run on the Z80-MBC2 (I can use gtkterm to send the file and look at the result, can even toggle DTR to reboot before trying the next benchmark).

To generate similar graphs for the score, I'd need to automate the sending of the .ihx file and getting the result. I guess I could write a C program to interface with the serial port. But maybe there is some simple way to do it with some bash script or so.

from z80-mbc2.

May be using a bash script + a minicom macro (not sure if gtkterm can handle macros).
This way you can automate the upload for sure, and may be the output capture too.

BTW: Inside portme.c you did on the clock():

 unsigned long clock(void)
 {
   long ret;
   do
	   ret = ticks;
   while (ret != ticks);
   return(ret);
 }

while I was expecting something as:

 unsigned long clock(void)
 {
   long ret;

   __asm
      di
   __endasm;

   ret = ticks;

   __asm
      ei
   __endasm;

   return(ret);
 }

Just curious if there is any particular reason to prefer the first one...

from z80-mbc2.

Just curious if there is any particular reason to prefer the first one...

Not really. It is just the style I'm used to since the first Z80 platform I wrote software for was the ColecoVision video game system. There, the non-maskable interrupt is used for the timer.

from z80-mbc2.

I don't think I can reset the system from a minicom script (I can reset the system from minicom using the hangup command, but see no way if issuing minicom commands from minicom scripts). That leaves other options: a bash script that resets the system some other way before invoking the minicom script. Or just write a C program instead of trying to use scripts.

from z80-mbc2.

I normally use a bash script to call minicom and execute the loading with a minicom script (see the test.zip file I posted here some posts ago).
When you call minicom from the bash script the Z80-MBC2 board is automatically reset by the DTR signal.
Then the minicom script waits a while just letting the Z80-MBC2 to complete the boot into iLoad, and after the hex file is transmitted.

from z80-mbc2.

When you call minicom from the bash script the Z80-MBC2 board is automatically reset by the DTR signal.
Then the minicom script waits a while just letting the Z80-MBC2 to complete the boot into iLoad, and after the hex file is transmitted.

Doesn't work for me. I don't see the Z80-MBC2 reset when minicom starts. But I can reset it manually using Ctrl-A H from within minicom.
Maybe you have a minicom configuration file that does the reset for you? If yes, could you show it?

from z80-mbc2.

I haven't any custom conf file for minicom. I've just checked that minicom resets the board when you start it (with the DTR line).
Instead if I do a Ctrl-A H nothing happens.
Are you really sure to use the right signal (DTR) from the USB-serial adapter?

from z80-mbc2.

I've read this from the minicom manual:

So check if you have a non zero value inside minicom for this parameter:

from z80-mbc2.

Anyway it works also if set to 0...

from z80-mbc2.

I haven't any custom conf file for minicom. I've just checked that minicom resets the board when you start it (with the DTR line).
Instead if I do a Ctrl-A H nothing happens.
Are you really sure to use the right signal (DTR) from the USB-serial adapter?

Looks good to me: I use a C232HD cable, gray wire connected to the pin marked "DTR" on the board, according to the cable manual, gray is DTR.

from z80-mbc2.

Just re-checked now with a FTDI adapter using a FT232RL (while yours cable uses a FT232HL):

DTR works as expected (goes LOW when minicom is executed).

This behavior should be with any IC and any terminal emulation SW (e.g. Tera Term under Windows works the same).

I've no idea about your strange behavior...
Try to find with a DVM if there is a signal that goes low when minicom is executed (or get a different adapter on ebay...).

PS: I've also used CP2102 and CH340G USB-serial adapter ICs with the same behavior on linux and win.

from z80-mbc2.

I usually use a CP2102 based adapter (on both linux and win):

You can find it at about 2$ on ebay.

from z80-mbc2.

I think my hardware is fine, I'm just fighting with minicom. After all it works with gtkterm (which doesn't have scripts though).
I think I figured out the DTR issue: When killing minicom, the serial port was in an unuseable state, so the dtr worked when starting minicom for the first time, but not on subsequent starts of minicom. Now that I know about the issue I can work around it while trying to get a bit further.

So I now do get the reset on minicom start. Next I want to find out how to send the hex file using minicom. For now, I'm trying with a 526 B "Hello, world!" program hex file, which work fine for me when using gtkterm.

1. Manual attempt: I start minicom using "minicom -w -D /dev/ttyUSB1". When the message from the "Intel-Hex Loader", "Waiting input stream..." appears, I press Ctrl+A S, select "ascii" in the menu, select the file in the next menu, press Enter. I get a Window "ascii upload - Press CTRL-C to quit" that displays "0.0 Kbytes transferred at 19 CPS" and no further output on the screen.
2. Script attempt. I start minicom using "minicom -w -S minicom.txt -D /dev/ttyUSB1". In minicom, I don't see the any message from the "Intel-Hex Loader", but I do see "ASCII upload of "out.hex"
   Line delay: 100 ms, character delay 0 ms" and after a while I get a message about a timeout. minicom won't react to anything, so I have to kill it.

from z80-mbc2.

Strange you have all these problems with minicom.
If I try to kill minicom closing the CLI window where it runs and than re-open a new one, it works fine.
I'm using minicom 2.7.1. on a linux mint 20.2 (Cinnamon 64 bit) system.

from z80-mbc2.