Suitable for automated benchmark execution?

[spth]

Hello, I am looking for an SBC that can be easily programmed from a host system and interface with that host system via a serial connection. This should not require any mechanic interaction (i.e. no plugging / unplugging / EPROM insertion, etc).

Basically, I want to use it as one can use modern development boards for microcontrollers.

Will this work with the RC2014? If yes, is where can I find the relevant documentation? I've had a look at https://github.com/RC2014Z80/RC2014/tree/master/BASIC-Programs/hexload but it looks as if I still have to press the reset button each time to load a new program (which is a problem when I want to load and execute hundreds of programs in sequence).

Background: The SDCC compiler has various backends. To track code size and performance regressions, benchmarks are compiled with new SDCC revisions and executed on STM8 and MCS-51 boards (resulting in the graphs at https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/).

However, currently no z80-related port is tested that way (despite Z80/GameBoy/Z180 retrocomputing being an important use case for SDCC). So I'm looking for a well-documented SBC that uses a Z80 or related to close that gap.

[RFC2795]

Hi Phillip,

Almost all of the RC2014 range (Micro, Mini, Classic II, Plus and Pro) all ship with Small Computer Monitor (SCM) on ROM. SCM includes the ability to receive Intel Hex files as well as many other features. See https://smallcomputercentral.wordpress.com/small-computer-monitor/small-computer-monitor-v1-0/ and the tutorial here https://smallcomputercentral.files.wordpress.com/2018/05/scmon-v1-0-tutorial-e1-0-0.pdf

The only issue which is not addressed directly is remote reset, however, it is fairly trivial to reuse the DTR pin on the FTDI cable for reset, similar to the way it's used with boards like the Arduino.

[feilipu]

Hi Philipp,

I'm just reworking a RC2014 MS Basic currently, and have added HLOAD which is a serial upload command integral to MS Basic. It will automatically set the correct memory locations to run assembly/C when uploaded.

Then the program can be run from within Basic as a USR(x) application, so you could script some stuff from within Basic.

EDIT just tested Basic scripting, and it doesn't work because I reset the Basic variables / strings environment on leaving the HLOAD function (but keeping programs as token strings). The compiled program under test can still be initiated from either the immediate command line, or from within MS Basic.

list
10 PRINT "Philipp's testing script..."
20 PRINT USR(0) : REM now the program is running, and will return a zero (or other return if desired).

hload   <-- Basic will wait until the HEX program is uploaded
Ok

run
Philipp's testing script...
0
Ok

What is missing is a clean hardware RESET command from within Basic, though of course all the functions are present internally for a cold start. It won't be any trouble to add this to Basic.

But, then there is an issue of needing a hard RESET capability. I'd suggest something like an ESP01 could be hooked up to provide a reset pulse if needed, and I'm sure someone could knock up a PCB for you to do that pretty easily. If there was no other apparent solution. EDIT The FTDI DTR pin solution above is clearly an easier option.

[feilipu]

Added an issue with respect to HLOAD. https://github.com/feilipu/NASCOM_BASIC_4.7/issues/2

[feilipu]

I've "finished" a new release of MS Basic for 32kB RC2014 types (Classic, Mini, & Micro) that has both a HLOAD to upload Intel HEX and a RESET function to reset to the cold start equivalent state. Realised that those keywords don't need to be programmable, as the RC2014 will be attached to the host machine anyway.

See if these two new keywords are sufficient for the purpose?

[feilipu]

@spth how did you get on with your RC2014 kit?

[spth]

I assembled the kit, and did a first quick test to check that the board works, but so far haven't really done anything else with it.

Instead I revived OpenRabbit (https://github.com/spth/OpenRabbit) and improved the Rabbit backends in SDCC, and intend to use an RCM board for the benchmarking. In the long term I might still also use a Z80 board: The Rabbit is a Z80-derivative, but there are some important differences in the instruction set, so it would be good to have a plain Z80 besides the Rabbit for SDCC benchmarking.

[feilipu]

@spth perhaps comment your thoughts here on the topic of Rabbit support within z88dk?

[feilipu]

Closed with Rabbit SBC.