RTM/Z80 - Retro Tiny Multitasking system for Z80

[ladislau szilagyi]

Hi,

My name is Ladislau Szilagyi, I'm 67 and I'm a big fan of Z80 retro computers.

I just published on GitHub ( https://github.com/Laci1953/RTM-Z80 ) my RTM/Z80 project.

RTM/Z80 is a multitasking kernel, built for Z80 based computers, written in Z80 assembly language, providing its users with an Application Programming Interface (API) accessible from programs written in the C language and the Z80 assembly language.

It is intended to be a simple and easy to use learning tool, for those who want to understand the tips and tricks of the multitasking software systems.

RTM/Z80 is a “low profile” multitasking system; it is written entirely in Z80 assembler language and uses as a building platform the vintage HiTech Z80 software, which may be run on a “real” Z80 computer or on a Z80 “simulator”. However, you can use also the C language and “mix” C code with Z80 assembly code when writing RTM/Z80 applications.

RTM/Z80 does not pretend to be a “real-time” system; for this target, you need much more powerful CPU power; the 7.3728 MHz Z80 is a low-placed processor in this perspective.

Building RTM/Z80 applications does not imply the use of any Unix/Linux development platform. All you need is CP/M, knowledge of Z80 assembly language or C language and being used to operate the HiTech tools (assembler, C compiler, linker).

RTM/Z80 is not a “concurrent” of the many Z80 multitasking systems available on the market, it is only a learning tool for those who want to understand the “tips & tricks” of multitasking; because of this, it’s structure is simple and straightforward. However, the author tried to build also a versatile and efficient system, with performances comparable with other popular Z80 multitasking systems.

I finished the testing on Z80SIM and RC2014 (SC108 and Memory Module).

I'm waiting for your opinions and suggestions!

regards,

Ladislau 

[Karl Albert Brokstad]

Nice project!

Karl

-----
Karl Albert Brokstad
Kirkeveien 9B, 5072 Bergen
98843314
ka...@brokstad.no

[Jay Cotton]

I looked at the project, looks very cool. 

Need pointers to 'zas' as used in the build scripts, and

any other tools that are needed to build.

thanks

jc

[Jay Cotton]

Well RTFM.  Its in the .pdf file.

[Jay Cotton]

I have built all but rtsys.as in situ.  

D>zas rtsys.as

RTSYS.AS:1456:  Out of memory

I have  55302 Bytes in TPA.

[ladislau szilagyi]

Hi Jay,

I use Z80SIM as a dev platform, 

When booting, it says:

"64K CP/M Vers. 2.2 (Z80 CBIOS V1.2 for Z80SIM, Copyright 1988-2007 by Udo Munk)"

...so, I think it runs on a 64KB RAM virtual CP/M, perhaps that's the explanation.

Anyway, I'm trying to "split" rtsys.as in two pieces, to solve your problem...

Ladislau

[Jay Cotton]

Do you have a way to build on your sc108 ?  I think you may need to split rtsys.as into 3 parts.

There is a lot of code there.

In the mean time, I will be pulling in Udo's code for a test build.  

tnx

jc

[ladislau szilagyi]

Hi Jay,

now you have rtsys1.as and rtsys2.as , I dumped the "old" rtsys.as

Also make.sub is changed.

All the link commanda must include now rtsys1.obj and rtsys2.obj, instead of only rtsys.obj (see the manual)

I refreshed also the manual.

I tested the new code on Z80SIM and SC108 (RAM version), it's OK.

Now, I hope zas will compile rtsys also on CP/M machines with smaller RAM sizes.

Thanks to pointing out the issue...

regards,

Ladislau

PS. I have not yet a working CP/M on my RC2014. I have SC112+SC108+SC110+Digital IO, but my CF card is not working yet (it seems the CF card containing CPM has some problems...)

If you have SC108, you may try directly to run the demo (DEMO/HEX/SC108/rtmdemo.hex).

Load first HEXBOOT.HEX (from RESOURCES), run-it with gE000 then feed rtmdemo.hex 

[Jay Cotton]

Hi Ladislau:

Thanks for working on this, still having problems however.  Is this code intended to build on the z80 h/w ?  It seems to be 

very close to working, just a bit more effort.  I'm guessing we are running out of symbol

space in the assembler.

I suspect that the z80pack simulator is not checking for calloc over run, since linux et.al have access to

lots of ram.  This may explain the problems I am seeing with a native build.

BTW:  I can build on using the cpmsim code, and run it on cpmsim.  The .COM file does not work on

the h/w however.  I suspect the config.mac is at fault.

results of latest build attempt on my z80 machine.

D>zas rtsys1.as

config.mac:289: No space for macro def'n

D>xm r rtsys2.as

XMODEM v12.5 - 07/13/86

RBC, 28-Aug-2019 [WBW], ASCI

Receiving: D0:RTSYS2.AS

5724k available for uploads

File open - ready to receive

To cancel: Ctrl-X, pause, Ctrl-X

CKCKCK

Thanks for the upload

D>zas rtsys2.as

config.mac:261: No space for macro def'n

I will be out of town until late Wednesday, so I will not

be able to assist you in further debugging until then.

tnx

jc

[ladislau...@euroqst.ro]

Hi Jay,

so you succeded to build-it on Z80SIM (+ CPMSIM )...that's ok.

The demo (rtmdemo.hex, transformed to rtmdemo.com) will work on any
Z80SIM implementation, because it uses only the Z80SIM's built-in real
time clock.

What do you mean by "The .COM file does not work on the h/w however."

You are running Z80SIM on Cygwin on Windows, right?

What's the outcome of running RTMDEMO.COM on Z80SIM ?

About the ZAS issue on 56KB CPM, I will take a look immediately.

regards,
Ladislau

PS. On RC2014, RTM/Z80 needs to be run on SC108 (because of IM2)...

>> now you have rtsys1.as [1] and rtsys2.as [2] , I dumped the "old"
>> rtsys.as [3]

>>
>> Also make.sub is changed.
>>
>> All the link commanda must include now rtsys1.obj and rtsys2.obj,
>> instead of only rtsys.obj (see the manual)
>>
>> I refreshed also the manual.
>>
>> I tested the new code on Z80SIM and SC108 (RAM version), it's OK.
>>
>> Now, I hope zas will compile rtsys also on CP/M machines with
>> smaller RAM sizes.
>>
>> Thanks to pointing out the issue...
>>
>> regards,
>> Ladislau
>>
>> PS. I have not yet a working CP/M on my RC2014. I have
>> SC112+SC108+SC110+Digital IO, but my CF card is not working yet (it
>> seems the CF card containing CPM has some problems...)
>>
>> If you have SC108, you may try directly to run the demo
>> (DEMO/HEX/SC108/rtmdemo.hex).
>> Load first HEXBOOT.HEX (from RESOURCES), run-it with gE000 then feed
>> rtmdemo.hex
>>
>> Pe sâmbătă, 14 august 2021, la 06:36:41 UTC+3, Jay Cotton a
>> scris:
>> Do you have a way to build on your sc108 ? I think you may need to

>> split rtsys.as [3] into 3 parts.

>> There is a lot of code there.
>>
>> In the mean time, I will be pulling in Udo's code for a test build.
>>
>>
>> tnx
>> jc
>>
>> On Friday, August 13, 2021 at 7:50:47 PM UTC-7
>> ladislau...@euroqst.ro wrote:
>> Hi Jay,
>> I use Z80SIM as a dev platform,
>>
>> When booting, it says:
>>
>> "64K CP/M Vers. 2.2 (Z80 CBIOS V1.2 for Z80SIM, Copyright 1988-2007
>> by Udo Munk)"
>>
>> ...so, I think it runs on a 64KB RAM virtual CP/M, perhaps that's
>> the explanation.
>>

>> Anyway, I'm trying to "split" rtsys.as [3] in two pieces, to solve

>> your problem...
>>
>> Ladislau
>>
>> Pe sâmbătă, 14 august 2021, la 05:09:17 UTC+3, Jay Cotton a
>> scris:

>> I have built all but rtsys.as [3] in situ.
>>
>> D>zas rtsys.as [3]
>> RTSYS.AS:1456 [4]: Out of memory

> --
> You received this message because you are subscribed to the Google
> Groups "RC2014-Z80" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to rc2014-z80+...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/rc2014-z80/15f2c796-3c36-422e-827f-345622fb236bn%40googlegroups.com
> [5].
>
>
> Links:
> ------
> [1] http://rtsys1.as
> [2] http://rtsys2.as
> [3] http://rtsys.as
> [4] http://RTSYS.AS:1456
> [5]
> https://groups.google.com/d/msgid/rc2014-z80/15f2c796-3c36-422e-827f-345622fb236bn%40googlegroups.com?utm_medium=email&utm_source=footer

[ladislau szilagyi]

Hi Jay,

I modified both files (rtsys1.as and rtsys2.as), I suspect the cause of "out-of-memory" was : too many GLOBAL declarations...let's see if ZAS will assemble now these new versions.

Ladislau

[Tadeusz Pycio]

A very interesting project. I ran it on a different set of modules, CPU - # 21d, ROM-RAM - # 42d from Karl and SIO+CTC SC110 from Stephen. It is worth working on the readability of messages, because they introduce a certain chaos.
Great and missing idea!

[ladislau szilagyi]

Hi Tadeusz,

the issue with the order of the messages is because you did not followed "by-the-book" my recommendation from the manual: you MUST type EXI when prompted with ">" ;

This ">" is issued by the CMD task (console commands handler, with higher priority than the demo...), and if you issue any command (e.g. TAS), the messages from CMD and the messages from the DEMO will mix-up.

Try EXI-ting from CMD, then DEMO will start as designed; I hope it will be rewarding (hint: set the speed higher and higher...). I wait for your impressions about the demo...

My lesson: I will build the demo WITHOUT the CMD task included, so that it will start alone... 

regards,

Ladislau

[ladislau szilagyi]

Hi,

I've fixed the mixed messages problem : now, on GitHub, all the stored demos are built WITHOUT the CMD task.

Ladislau

[Jay Cotton]

Hi Ladislau:

Your fix to rtsys works for me.  Here is a build log from my SC131.

I can build on the z80 directly.

Tnx

JC

A>b:supersub d:make 

SuperSUB V1.1

A>D:

D>ZAS -J DLIST.AS

D>ZAS -J BALLOC.AS

D>ZAS RTSYS1.AS

D>ZAS -J RTSYS2.AS

D>ZAS -J RTCLK.AS

D>ZAS -J QUEUE.AS

D>ZAS -J MAILBOX.AS

D>ZAS -J IO.AS

D>ZAS -J SNAPSHOT.AS

D>ZAS -J HEXLOAD.AS

D>ZAS -J UTIL.AS

D>ZAS -J CMD.AS

D>ZAS BOOT.AS

D>ZAS -J CSV.AS

D>ERA RT.LIB

D>LIBR R RT.LIB RTSYS1.OBJ RTSYS2.OBJ CMD.OBJ SNAPSHOT.OBJ 

module CMD.OBJ defines no symbols (warning)

module SNAPSHOT.OBJ defines no symbols (warning)

D>LIBR R RT.LIB HEXLOAD.OBJ IO.OBJ QUEUE.OBJ RTCLK.OBJ MAILBOX.OBJ

module HEXLOAD.OBJ defines no symbols (warning)

D>LIBR R RT.LIB BALLOC.OBJ DLIST.OBJ UTIL.OBJ BOOT.OBJ CSV.OBJ

module BOOT.OBJ defines no symbols (warning)

[ladislau szilagyi]

Wow, that's great!

Thanks for your help, I really appreciate-it!

regards,

Ladislau

PS. Did you managed to run the demo ( on Z80SIM or SC108 ) ?

[Tadeusz Pycio]

Ladislau, you were right, it was in the documentation (RTMF :-).  Demo v1 works with option 1 and EXI, demo v2 with option 2.

[ladislau szilagyi]

Hi Tadeusz,

Thanks for pointing out this configuration: " CPU - # 21d, ROM-RAM - # 42d from Karl " ... 

I was wondering if I could find these boards now on Tindie, but it seems not , they are "retired"...

According to you, which is the best pair of Z80CPU board and (128KB RAM+32KB EPROM) board, on the market, of course compatible with RC2014 bus? 

regards,

Ladislau

[Tadeusz Pycio]

Hi Ladislau ,

This is a difficult question, any module that works properly. You will have a problem with the 128kB module, # 45d is available from Karl, but he also has the same problem with the use of the other half as the SC108. There is a project on Github, a 128kB + 128kB module https://github.com/PickledDog/rc-256page, I plan to release 16kB ROM 32-256kB RAM, so it will not be what you are looking for. I admit, I do not know a module that would meet your expectations. Maybe it's an idea for a project like this.

[Alan Cox]

On Sun, 15 Aug 2021 at 03:24, ladislau szilagyi <ladislau...@euroqst.ro> wrote:

Hi Tadeusz,

Thanks for pointing out this configuration: " CPU - # 21d, ROM-RAM - # 42d from Karl " ... 

I was wondering if I could find these boards now on Tindie, but it seems not , they are "retired"...

According to you, which is the best pair of Z80CPU board and (128KB RAM+32KB EPROM) board, on the market, of course compatible with RC2014 bus? 

 

It depends what your requirements are - generally the 128K boards in RC2014 are very much 64K and the extra address pin is wired to something.  That means all the RAM changes at once between the two banks and writing code to use it effectively is a little bit exciting. It is usable with care - I've got CP/M RAMdisk drivers for it and Fuzix knows how to use it, although that was quite tricky to get working.

If you want to run ROMWBW you need the divide at the 32K line, for other things like MP/M you really want at about 56K or higher and for your own OS who knows. 

Most retro 32K/32K style systems use 512K because the 512K RAM is not really much different in price and also because the required banking logic is the same and the gates needed come four per chip so you've got A15/A16/A17/A18 anyway.

Alan

[ladislau szilagyi]

Hi Tadeusz & Alan,

yes, you're both right, there is no simple answer to my question. 

I need 32KB EPROM to store several (4) RTM/Z80 versions + Watson utility program.

I insist having 128 KB RAM ( 2 X 64KB pages) also because my Watson utility program.

I found very convenient to have a 64 KB RAM free space to save my "main" 64KB RAM, in case this is needed (breakpoint or shutdown), and then to "extract" data from there to show the aftermath of an application run.

Thanks anyway, I will wait for other opinions as well...

Ladislau

[Bill Shen]

Hi Ladislau,
I want to try your multitask kernel on a different RC2014 hardware, K80.   It has been 3-1/2 years since I worked on K80 so this is also a familiarization process for me.  K80 is a Z80 with KIO (Z84C90) which has integrated SIO, CTC, PIO, and interrupt controller.  Mode2 interrupt is supported on KIO.   K80 system clock is 22MHz which is 3 times faster than standard RC2014 7.37MHz clock.  CP/M2.2 was ported to K80 and I do not use interrupt for console I/O which is an important point mentioned in your user manual.  I am able to compile your source files with HiTech C as shown below.

I have not run RTMDEMO because I know KIO has different I/O addresses than SC110.  So one thing I need help is modifying the rtclk routine so it can correctly access CTC in the KIO.  The base I/O address of KIO is 0x90 and CTC is located at 0x94 (chan0), 0x95 (chan1), 0x96 (chan2), and 0x97 (chan3).  There may also be other hardware-specific changes I'm not aware of.  Thanks,
  Bill

-------------------------------------

a>submit make.sub

a>ZAS -J DLIST.AS

a>ZAS -J BALLOC.AS

a>ZAS RTSYS1.AS

a>ZAS -J RTSYS2.AS

a>ZAS -J RTCLK.AS

a>ZAS -J QUEUE.AS

a>ZAS -J MAILBOX.AS

a>ZAS -J IO.AS

a>ZAS -J SNAPSHOT.AS

a>ZAS -J HEXLOAD.AS

a>ZAS -J UTIL.AS

a>ZAS -J CMD.AS

a>ZAS BOOT.AS

a>ZAS -J CSV.AS

a>ERA RT.LIB
No file
a>LIBR R RT.LIB RTSYS1.OBJ RTSYS2.OBJ CMD.OBJ SNAPSHOT.OBJ HEXLOAD.OBJ IO.OBJ QUEUE.OBJ RTCLK.OBJ MAILBOX.OBJ

module CMD.OBJ defines no symbols (warning)

module HEXLOAD.OBJ defines no symbols (warning)

a>LIBR R RT.LIB BALLOC.OBJ DLIST.OBJ UTIL.OBJ BOOT.OBJ CSV.OBJ

module BOOT.OBJ defines no symbols (warning)

I have not run RTMDEMO because I know KIO has different I/O addresses than SC110.  So one thing I need help is modifying the rtclk routine so it can correctly access CTC in the KIO.  The base I/O address of KIO is 0x90 and CTC is located at 0x94 (chan0), 0x95 (chan1), 0x96 (chan2), and 0x97 (chan3).  There may also be other hardware-specific changes I'm not aware of.  Thanks,
  Bill

[ladislau szilagyi]

Hi,

I just added a new chapter in the manual : Porting RTM/Z80 to other hardware

Ladislau

[ladislau szilagyi]

Hi Bill,

I found an RC2014 - compatible KIO based board ( https://www.z80.no/modules2/67c.html ), I will try to buy-it (it's only an experimental board, so it may take some time...) then I will port RTM/Z80 to this new hardware.

regards,

Ladislau

[Tadeusz Pycio]

Hi Ladislau ,

I searched the available projects for a memory module and found nothing that matched your criteria. Perhaps it is worth considering the implementation of the MMU for RTM-Z80, which will give more flexibility and scalability for this system. Several modules are available to do this (eg Spencer 512k ROM + 512k RAM Module, Karl #65a, ...).

Hi Tadeusz & Alan,

yes, you're both right, there is no simple answer to my question. 

I need 32KB EPROM to store several (4) RTM/Z80 versions + Watson utility program.

I insist having 128 KB RAM ( 2 X 64KB pages) also because my Watson utility program.

I found very convenient to have a 64 KB RAM free space to save my "main" 64KB RAM, in case this is needed (breakpoint or shutdown), and then to "extract" data from there to show the aftermath of an application run.

Thanks anyway, I will wait for other opinions as well...

Ladislau

Hi Tadeusz,

Thanks for pointing out this configuration: " CPU - # 21d, ROM-RAM - # 42d from Karl " ... 

I was wondering if I could find these boards now on Tindie, but it seems not , they are "retired"...

According to you, which is the best pair of Z80CPU board and (128KB RAM+32KB EPROM) board, on the market, of course compatible with RC2014 bus? 

 

[flyingbird]

Hi,

first of all - I can say that this is awesome project. I plan to try it with my RC2014 Pro.

Manual page 46 says: 'Running an RTM/Z80 application on RC2014', required HW: SC108 and SC110 boards.

But... I have SC108 + official SIO/2 + SC102 standalone CTC module. I have established Interrupt chain
between SIO/2 and CTC like this:
http://www.valachnet.cz/lvanek/diy/rc2014/img/ctc_setup.png

I can ask - which CTC channel(s) is used by RTM/Z80 ? I need this info to correctly put jumpers on CTC board.

Best Regards,
Lumir

Dne pondělí 16. srpna 2021 v 9:28:14 UTC+2 uživatel Tadeusz Pycio napsal:

[ladislau szilagyi]

Hi Lumir,

here is the code used in rtsys1.as to initialize the real time clock :

_InitInts:
di ;disable interrupts
;
; Real Time Clock
;
;CTC_0, CTC_1, CTC_3
;
ld a,00000011B ;disable int,timer,prescale=16,don't care,
;don't care,no time constant follows,reset,control
out (CTC_0),a ;CTC_0 is on hold now
out (CTC_1),a ;CTC_1 is on hold now
out (CTC_3),a ;CTC_3 is on hold now
;
;CTC_2 Real Time Clock
;
ld a,10110111B ;enable ints,timer,prescale=256,positive edge,
;dont care,const follows,reset,control
out (CTC_2),a
ld a,144 ;7.3728 MHz / 256 / 144 ==> 200Hz = 5ms interrupt period
out (CTC_2),a
;
;CTC interrupt vector
;
ld a,00000000B ;adr7 to adr3=0,vector ==> INT level 2
out (CTC_0),a ;set vector
;

The only problem is related to the clock time period. 

As you see, in the case of SC110,  I used 5ms (This was suggested in the Steve Cousins SCM documentation...)

If you prefere 10ms, please change your code accordingly, but take care to modify TICS_PER_SEC in config.mac

regards,

Ladislau

[ladislau szilagyi]

Hi Tadeusz,

wow, MMU...what a tempting ideea !!!

I must study carefully this topic... 

About the "best pair: CPU and memory board" , I tend to think about : Karl's  #22c Z80 CPU Module, and Phillip Stevens's Memory Module. 

Only a personal opinion...

Why I raised this question?

Here is the story...

I currently use SC108 + Phillip Stevens Memory Module, because I want to test my RTM/Z80 EPROM version... but, in order to do this, I must first remove the RAM and EPROM from the SC108, and insert my RTM/Z80 EEPROM in the Memory Module. That's not very good for the EPROMs, I risk ruining the SCM EPROM...

regards,

Ladislau

[ladislau szilagyi]

Hi Lumir,

I forgot to mention the code to "shutdown" the clock:

In rtsys1.as

StopHardware:
;
; stop CTC_2

;
ld a,00000011B ;disable int,timer,prescale=16,don't care,
;don't care,no time constant follows,reset,control

out (CTC_2),a ;CTC_2 is on hold now

regards,

Ladislau

[ladislau szilagyi]

Hi all,

If you want to "port" RTM/Z80 to other hardware, be aware that I published today a new manual, containing at the end a chapter named: "Porting RTM/Z80 to other hardware".

As you noticed, I was able until now to test my system only on:

- Udo Munk's Z80SIM

- RC2014 SC108 + SC110 + Digital I/O module + Phillip Stevens Memory Module

That's all the hardware I have!

Please understand my perspective: I train testers (more than 2500 of my students are ISTQB certified- foundation and/or advanced level). 

I am also a tester.

I will never publish a code not tested good enough. (yes, I know, there are some not detected-yet bugs left, even in my published code, but that's normal :)

So, I cannot say: please, give me your hardware's data, I will modify the source code, and good luck!

I will always publish code ONLY after testing-it carefully.

That's the also reason why I delayed publishing RTM/Z80 on GitHub ( I waited a couple of months before receiving the Memory Module and the components, and I preferred to test-it as a ROM/RAM platform).

I will make any effort to buy all kinds of Z80 hardware configurations, in order to port my system to as-many-as-possible hardware configurations, but this will take time.

regards,

Ladislau

[Bill Shen]

Ladislau,
Thank you for adding the porting guide.  Listing the hardware dependent constants are very useful to me because I have several different Z80/Z280 hardware that I like to port RTM.

As I read the RTM/Z80 manual (v1.4), I see running RTMdemo on Udo Munk's Z80SIM is straightforward, but running RTM/Z80 on RC2014 is quite complicated, involving converting program to loadable hex file, load into RC2014 RAM using SCMonitor, and bootstrap into RTM/Z80.  My question is this:  RC2014 can run CP/M with the addition of a compact flash board and HiTech C can be installed on the CF disk.  So is it possible to compile RTMdemo on RC2014's native CP/M environment then run much like it is ran on Udo Munk's Z80SIM, except it will be on the real hardware?

In fact, I did transferred your RTM source files to K80 and compiled them correctly with the make.sub batch file in about 1 minute 20 seconds.  It would be nice if I can then just type 'rtmdemo' and start up the demonstration program on K80.
  Bill

[ladislau szilagyi]

Hi Bill,

unfortunately, the answer is NO.

On CP/M, you need a real time clock to do multitasking, and only CPUSIM on Z80SIM provides this clock.

If you look at rtsys1.as line 535 on, you will notice this code:

ld a,jp ;valid ONLY for Z80SIM
ld (38H),a ;RTC int at RST 38H
ld hl,_RTC_Int
ld (39H),hl
ld a,1 ;start RTC ints
out (27),a
im 1

Here, I use Udo's I/O port implementation to start the real time clock! 

Unfortunately, this will NOT work on an usual CP/M implementation.

If you manage to start the K80 clock, the same way I did-it in Z80SIM, then you may give-it a try.

Be careful to include also stopping the clock (line 546)

BUT: see the page 43 of the manual: the RTM/Z80 on CP/M implementation does not use interrupts for serial I/O !!!

This means I "simulated" the interrupts, using direct calls to the interrupt handling routines (this means, for example, that a WRITE will loop until all characters are written).

Ups: that's another problem... I did NOT use CALL 5 to do console I/O, instead I used Udo's ports ( IN A,(1), OUT (1),A ) ... you will find these in io.as

So, you will need to change that as well.

Honestly, I do not think it's a good idea. It will work, but it's only a compromise... why not having interrupts also on console I/O ?

I will get soon a KIO board, and start porting my system to KIO-based configurations... how soon, well, ask Romanian Postal services !!!

regards,

Ladislau

[Bill Shen]

Hi Ladislau,
I do not use interrupt for console I/O for the K80 CP/M implementation.  This is because interrupt routine is often not fast enough to handle serial receive at 115200.  Polling console I/O is actually not that unusual for CP/M implementations.  In some of my designs I have hardware console receiver but use Z80 to bit-bang console transmitter which is surprisingly efficient.

My thought on compiling RTMdemo on K80 and then run it as a CP/M program is this:  Once I have changed the config.mac to run on K80 and then compile RTMdemo.c on K80's native HiTech C, the resulting RTMdemo program should be using K80's CTC timer for generating real time interrupt; it should also use the K80's SIO as console I/O.  So instead of convert RTMdemo to hex file, xmodem the RTMdemo.hex to my workstation, use the workstation to load hexboot.hex first and then use hexboot to load RTMdemo.hex, I can just run RTMdemo.com as a CP/M program.

Have I missed some critical steps?

  Bill

PS, the existing hexboot.hex won't work on K80 because it assumes the default SIO I/O addresses that are different from K80's SIO addresses.  I tried changing SIO I/O addresses in hexboot.as and recompile, but I'm not successful so far.  I afraid I'm not very good with ZAS assembler.

[ladislau szilagyi]

Hi Bill,

1. about hexboot: it was designed to be loaded under Steve Cousins SCM as a .HEX file and executed at 0E000H. Its purpose is to prepare the "shadow code" in the upper 64KB RAM in order to execute the snapshot (move full lower 64KB RAM to upper 64KB RAM, at RTM/Z80 shutdown or when reaching a breakpoint), then to store a tiny "exit to SCM" code, then to load the RTM/Z80 user application as a .HEX file, optionally install some breakpoints, and then boot RTM/Z80. It needs to de-select the low 32KB EPROM, in order to load the user app. The "exit to SCM" code, called at shutdown, will select again the low 32KB EPROM and re-boot SCM.

This being said, you must set, in hexboot.as, RAM128K equ 0 (this way, the high 64KB RAM will be ignored). Then you must comment-out all the *_RAM macros (they select/deselect low/high RAM and/or EPROM). Then, by setting the correct SIO ports (line 24-25) and assembling, you will obtain a custom-hexboot. I preferred to build-it at 0E000H because at this address will be stored the dynamic memory, and below-it, all the sys and user code.

2. About compiling rtmdemo on K80: you must first modify :

config.mac : ports for SIO & CTC, TICS_PER_SEC

rtsys1.as : _InitInts & StopHardware routines (in the NOCPM branch at line 131), the INTERRUPTS vector

In config.mac, use:

DEBUG equ 0 ;1=debug mode ON: verify task SP, task TCB, dealloc, lists, etc.
CPM equ 0 ;1=Runs under CP/M, 0=Runs on RC2014(SC108+SC110)
DIG_IO equ 0 ;1=RC2014 Digital I/O module is used
CMD equ 0 ;1=CON CMD task is included
RSTS equ 1 ;1=use RST for list routines (not for CP/M)
WATSON equ 0 ;1=Watson is used (not for CP/M)
C_LANG equ 1 ;1=Support for C language API
IO_COMM equ 0 ;1=Support for async communications I/O
MM equ 0 ;1=Memory Module is used, 0=SC108 is used
;
; ROM/RAM options (only if CPM=0)
;
RAM128K equ 0 ;0=only 64K RAM, 1= 2 x 64K RAM available
ROM equ 0 ;1=sys code on ROM, 0=ROM not used
BOOT_CODE equ 0 ;1=bootstrap code included in code, 0=no bootstrap code

Then:

J>c -iJ0: -c -o rtmdemo.c

J>zas rand.as

J>link

link> -x -z -Ptext=0,data,bss=0D000H -os.obj rtsys1.obj rtsys2.obj cmd.obj hexload.obj queue.obj io.obj rtclk.obj mailbox.obj \

link> balloc.obj dlist.obj util.obj snapshot.obj crtcpm.obj rtmdemo.obj rand.obj csv.obj libc.lib

J>objtohex s.obj rtmdemo.hex

(you must avoid to build a .COM - it will not work this way !!!)

Then, use the customized hexboot.hex to load & run rtmdemo.hex

"Transforming" hexboot.hex into hexboot.com will not work !!! .COM's are loaded at 100H, and the trick is to load the boot-er very high, to be able to load sys&app code starting from 0000H. 

3. About baud rate 115200 : I can assure you that my interrupt routines handle very well incoming characters ( see TESTS/twait.as, tswitch.as, tqt.as, tmt.as : it's about loading huge .HEX files while running other tasks too )

Have I missed something? Just ask me, I'm here to help. However, the "final solution" will be : me testing RTM/Z80 at home on a KIO-based hardware.

regards,

Ladislau

[Bill Shen]

Ladislau,
Thank you for explaining the inner working of hexboot.as.  I didn't understand the hardware dependency with SCMonitor, so I'll find a way of working around that.  My own K80 monitor is located at fairly high memory (0xB000-0xBFFF), it can also load Intel HEX file, and all my memory are RAM, so I may use it to load RTMdemo.hex as well.

I have tried your detailed instruction for compiling rtmdemo on K80.  It is not working yet, but I'm re-learning my own hardware after 3+ years so it is more likely my own misunderstandings.  I'll keep on working on it.  I'll also search around for hardware similar to SC108+SC110 so I can follow your process more closely.  Thanks for your help.

  Bill

[Bill Shen]

Ladislau,

RTMdemo is running on K80!

The problems were mostly mine:
1.  Several serial handshakes signals on KIO are floating; nDCD needs to be grounded and nCTS needs to be driven low to enable serial communication,
2.  Clock inputs to CTC are not connected.  These inputs need to be pulled up or connected to clock sources,
3.  KIO has a command register at I/O address 0x9E that needs to be written to enable interrupt daisy chain between CTC, SIO, and PIO,
4.  Because the serial port clocks are driven with 1.84MHz clock, to run the serial port at 115200, the SIO initialization table in rtsys1.as needs to be changed to x16 for write register 4,
5.  The RTC interrupt is measured at every 1.53ms.  This is because the Z80 clock is 24MHz.  The 8-bit time constant is not large enough to generate interrupt every 10mS.  I left the RTC interrupt at 1.53ms for now.

I made the changes to hexboot.as as you've suggested and the modified hexboot.hex can load RTMdemo.hex and run it.  However, the native K80 monitor can also load RTMdemo.hex and successfully start execution from 0x40.  K80 monitor does not have the ability of setting breakpoint, however.

Thanks for your help.  I'll try porting RTM to a SBC based on Z84C1516 which has integrated Z80+KIO.  If that's successful, I'll try porting to Z280.
  Bill

[ladislau szilagyi]

Hi Bill,

I'm glad you succeeded !

I'm amazed that RTM/Z80 works with a real-time clock set at 1.53ms ... I tested only clock periods of 5ms and 10ms ! 

The overall performance is however degraded by these too-frequent clock interrupts...

I'm waiting now to receive (by postal pack) an RC2014 KIO board... this will take some time.

When I will finish soldering, I will ask for your help, you're the only one I know with a functional KIO board...

You already gave me some interesting hints about enabling the interrupt daisy chain... but I will come back with more questions after receiving the board.

regards,

Ladislau

PS. Good luck with porting my system to  Z84C1516 and Z280.

[flyingbird]

Hi,

after two days of studying and installing it works on my Linux Debian machine. I must say that installing Z80-SIM is nothing for beginers. Now I have to test it on real RC2014 machine.

Bye,

Lumir

Dne středa 18. srpna 2021 v 6:35:09 UTC+2 uživatel ladislau...@euroqst.ro napsal:

[ladislau szilagyi]

Hi Lumir,

welcome to the Z80SIM club! Just joking :)

Im my opinion, once you have installed it, Z80SIM + CPMSIM is awesome. 

On a high-performance CPU (e.g.INTEL core 7), it's Z80 instruction execution speed is incredible.

I can compile all my 13 RTM/Z80 C tests in 5 seconds!

Lumir, I'm sorry for these 2 days lost, it will be more easy on the RC2014 ...

regards,

Ladislau

[flyingbird]

https://twitter.com/l_vanek/status/1429801998258483205

:-)

Bye,

Lumir

Dne středa 18. srpna 2021 v 10:24:06 UTC+2 uživatel ladislau...@euroqst.ro napsal:

[ladislau szilagyi]

Hi Lumir,

set-it faster, faster, faster ... :-)

https://twitter.com/i/status/1429817669847552001 

Ladislau

[flyingbird]

Hi all,

I have collected my knowhow here:

http://www.valachnet.cz/lvanek/diy/rc2014/index.html#RTM_Z80

Bye,

Lumir

Dne pondělí 23. srpna 2021 v 16:49:26 UTC+2 uživatel ladislau...@euroqst.ro napsal:

[Bill Shen]

Ladislau,
I thought you may be interested to know that I was successful in running RTMdemo on MicroZ which is based on Z84C15, Intelligent Peripheral Controller.  Z84C15 is basically Z80 + KIO, so the lesson-learned from porting RTMdemo to K80 is helpful.   I did have to make another modification to rtsys1.as mainly because I was sloppy with the serial port handshake signals /CTS and /DCD such that they are floating instead of pulling to ground.  I didn't want to solder wires to the SMT Z84C15, so I modified the initialization of SIO_A to disable the Auto enables which effectively disable the hardware handshake--probably not a good idea for applications that handle lots of serial traffic.   I'm glad having go through this exercise which identified some design deficiencies in MicroZ I need to correct.

I'll port RTM to another hardware, ZRC, before settling down to write some applications in HiTech C.
  Bill

[ladislau szilagyi]

Hi Bill,

thanks for let me know about porting my system to other hardware.

I did not know about Z84C15, nor about MicroZ. 

I currently use Tindie ( https://www.tindie.com/ ) , but they have not any hardware built with the  Z84C15...

By the way, if you want to test the serial port performance (K80, MicroZ, ZRC,...) I have in the folder TESTS a SUBMIT file ( timing.sub ) to build some programs for testing loading large .HEX files while performing other tasks execution. 

The basic one is TWAIT, it "waits" only for a .HEX file to be pasted on the terminal... the other programs execute run/stop tasks, or send/receive messages (or mails), or signal/wait while reading the .HEX. 

These programs were used also to compute the statistics on the duration of some typical operations  (alloc/dealloc, signal/wait, run/stop task, send/receive message or mail) .

Ladislau

[Bill Shen]

Ladislau,

You can find a number of discussions on Google forum retro-comp when search for "Z84C15".  Sergey Kiselev has a Z84C15 design (tiny_Z80) that may show up on Tindie if there are sufficient interests.  You can think of Z84C15 as Z80 with integrated I/O much like Z180 and Z280 but what makes Z84C15 interesting to software guys is it works harder at compatibility with discrete SIO, PIO, CTC parts so software developed on multiple RC2014 SIO, PIO, CTC, Z80 boards can easily port to the single-chip Z84C15.  Z84C15 is rated at 16MHz, but I've found it can be reliably overclocked to 30MHz.  It is about $5 on UTSource.

Thanks for the pointer to your TESTS folder.  I'm looking for multitasking examples so I can write my own programs to run in RTM.
  Bill

[ladislau szilagyi]

Hi all,

I added XMODEM serial communication protocol support functions to RTM/Z80.

You may find the new xmodem.as file published in the SOURCES folder.

I updated also the manual.

In the TESTS folder, there are now 2 more test programs (testxr.c and testxs.c).

I used TeraTerm's Transfer->XMODEM->Receive & Send to test my XMODEM interface.

regards,

Ladislau

[ladislau szilagyi]

Hi all,

I added in the API a function (LowToUp100H) to store data in the upper 64KB RAM memory (if available).

I uploaded all changed files to GitHub.

The user manual was updated too. 

I added also a new demo (a C program which receives a large 50KB text file via XMODEM and stores the text to the SC108 upper RAM bank).

regards,

Ladislau

[ladislau szilagyi]

Hi all,

I just added CP/M disk file I/O support.

If the host system is provided with file storage facilities ( disk, CF card, …) , RTM/Z80 offers the _bdos function to access the CP/M files stored on these disks, using the same interface as the CP/M’s BDOS.

The parameters are identical with those used when calling BDOS from CP/M : register C=BDOS function, registers DE = FCB address; register A contains the code returned as in the case of the BDOS call.

I updated the files & manual on GitHub.

In the TESTS folder, I added a test program (tbdos.as) to show the use of the _bdos function.

regards,

Ladislau

[ladislau szilagyi]

Hi all,

see a demo of receiving a large text file via XMODEM using TESTS/testxr.as (the received file is stored on the Upper 64KB RAM, then retrieved and printed at the console) 

https://twitter.com/ladislauszilag1/status/1435525449514463235

regards,

Ladislau

[flyingbird]

Hi all,

I have sucessfully tested testxs and testxr programs on my RC2014 Pro.

http://www.valachnet.cz/lvanek/diy/rc2014/rtm_z80

Thanks Ladislau for help with get it to work

Bye,

Lumir

Dne středa 8. září 2021 v 10:53:44 UTC+2 uživatel ladislau...@euroqst.ro napsal:

[ladislau szilagyi]

Hi,

I added in the folder DEMO a program that receives files via XMODEM and stores them on a CP/M disk (getxfile.c and getx.as).

The only restriction is the file size (smaller than 52KB).

Using TeraTerm's XMODEM, I used this program to send CP/M files from a Windows drive configured with cpmcbfs (http://www.nyangau.org/cpmcbfs/cpmcbfs.htm) containing my Z80SIM disk , to my CP/M disk on the CF card.

This way, I can move all my files from Z80SIM to RC2014's CF CP/M disks. 

At last, I have a functional CP/M hosted on RC2014, with all the CP/M programs, HiTech tools and my RTM/Z80 source files :)

regards,

Ladislau

[Fred Weigel]

Why a file size restriction? XMODEM sends a packet, then waits for ACK/NAK from receiver. The receiver gets a packet, validates it

(CRC/checksum), saves the packet, then sends ACK/NAK to get the next packet (or re-transmission). The timeout is 90 seconds

for the transmitter to wait for the initial NAK from the receiver. 7 seconds in between characters in a packet, and at LEAST 7 seconds

from end of packet to next ACK/NAK. This gives the receiver 7 seconds (actually more) to save 128 bytes to disk.

There is really no need to have more than 1 buffer, or multiple buffers to make a disk buffer. So... I am wondering (and I have NOT

looked at the source) why there would be a 52K restriction. Is that from your CP/M file system implementation?

Tell me to "Use the source Luke" and I will download and look...

But  I am curious (mostly about the design points of this).

FredW

[ladislau szilagyi]

Hi Fred,

I move first the received file to the upper 64KB RAM, and only after receiving all, I load slices from the upper 64KB RAM and write them to disk.

The problem is because I have at DFxx (in low & upper RAM) the routines that perform the up/low RAM copying, that's why the limit is around 52KB.
However, I noticed that, at least for CP/M .COM files & HiTech tools & my source files, all files are smaller than 52KB :)

Ladislau

[Fred Weigel]

Ladislau

Ah... got it. I will download and review... But... some quick observations (having written this sort of thing for 8080 and Z80 in the past)

1 - If you are using CP/M for its filesystem, the only thing that the kernel needs to do is not re-enter CP/M. Keep a request queue -or-

a simple mutex for CP/M entry. Either of these approaches works... and this is pretty much what MP/M did.

3 - It is possible to have the DOS component re-entrant. This is what we did at Philips back in the day.

4 - The core can respond to serial interrupt. With XMODEM, the best approach for high-speed  is to have a task await the first serial

receive interrupt -- then turn them off and receive each character polled. This assumes baud rate >9600 -- which is 1/10 second per packert.

5 - Your clock interrupt is either 10 or 60 per second (see point 4). At 10 per second a packet comes in a quanta.

6 - After the packet is received, a 128 byte disk write should be scheduled. Your next packet (serial) interrupt should use another

buffer. If the disk cannot keep up (VERY unlikely) easy to read and dump the packet and NAK it.

This design would keep up with ANY serial speed, minimize CPU and do it with only... 256 bytes of buffer space. Note though, that

at slow baud rates you may want to yield the processor in between characters (below 9600 baud). This depends on the speed

of your scheduler. We used to use a simple table with no priorities (simple round robin) to reduce the schedule overhead

(50 to 100 instructions). This allows up to 2000 context switches per second. Note that 9600 baud per character would need

you scheduler to do 1000 context switches per second. That is why I use 9600 baud as the cut-off.

I used to have all interrupt routines be maskable (using interrupt controller -- can also have a software mask). If not masked,

handle (possible event bit for this class of OS -- or semaphore in your case). that may wake up a task. The interrupt service

routine then exits directly into the scheduler, which will then pick the new task... That task is then responsible for reading data

from the device and re-enabling the interrupt level (software or hardware mask). The actual ISR (interrupt service routine)

is designed to be as short as possible in these designs - set a condition to wake a task, and exit to the scheduler.

The advantage to 8080/Z80 is there is absolutely no protection. A driver can be at "user level" and, arguably, should be.

I will download and look at what you are doing... I have a kernel that I used to use (40 years ago). Very small (measured

in hundreds of bytes). I'll see if I can dig it up for you...

FredW

[ladislau szilagyi]

Hi Fred,

please read my RTM/Z80 manual. 

It responds to all your observations. 

Here is a quick list of answers:

1. I am NOT using CP/M (my kernel overwrites the address area of CP/M BIOS & BDOS), instead I took parts of BIOS & BDOS and put them into my library of system functions; bdos calls are protected by a semaphore.

4. I have 5ms clock interrupts & SIO serial interrupts; I can handle incoming 115200 bauds because I use a 256 byte ring-buffer (e.g. it is possible to read a large .HEX file while running other tasks as well...)

5. At 5ms clock interrupts, I can handle well all sort of events ( timers, round robin scheduling...)

6. I preferred storing the 128 byte packet into a system queue, to be read by another task; practically, XMODEM I/O & timing is handled by a high priority task, and another low priority task will "consume" the packets. As I described, I preferred to store the incoming packets to the upper 64KB RAM, and retrieve them after the XMODEM protocol is finished, to be stored in the CP/M file, using my __bdos call.

I must admit that it is not the first time I'm doing this, some 40 years ago I wrote a multitasking kernel with almost the same shape as RTM/Z80...

But, again, please read the documentation (RTM-Z80 User Manual.pdf, in https://github.com/Laci1953/RTM-Z80 ). 

All system features are described extensively. 

regards,

Ladislau

[Fred Weigel]

Ladislau

Just looked at your OS

Just some observations:

1 - Yes, your OS is "real-time". The distinction between real-time and not real-time is NOT the speed of the processor. For

example, a microwave OS had better be real-time. What make your OS "real-time" is that you have bounded the

interrupt disable time. This gives predictable worst-case interrupt response. but...

2 - The behaviour of the system allocator is NOT bounded. So, you lose the benefit of "real-time". Allocation patterns

will be ok, until 4K (or so) is in use.

3 - Buffering is needed on serial at 115200 baud, because your scheduler cannot keep up. But... the ring buffer "saves

you" Yes, you are correct, you have 80 microseconds per character. But...

4 - At 7..8 Mhz you have 1 million instructions per second -- or 80 instruction budget. To respond to interrupt,

and schedule. So...

5 - The interrupts are NOT being handled at that rate (and, no, I do not have a Z80 running at that speed)

Instead, your code is interrupting, and polling... With GetSIOChars.

Which is what my design proposed... but explicitly.

Interrupt on the FIRST character of the packet. There will be approximately 132 characters in the packet.

(note -- you can reduce your ring buffer to save some bytes). On THAT interrupt, simply wake the reader

process - do NOT read the data. You have 2 character times (160 instructions) to dispatch that process.

That process will read the ENTIRE packet in before the next tick.

Effectively, that is what you ARE doing, but GetSIOChars is spinkled thoughout your core. 70 or so times,

Even in balloc?!?

Next part of the review -- why that form of allocation? Note that fragmentation is the killer here. I argue

that, given a fixed number of tasks, you have a limit to (1) the number of TCBs, (2) that limits the

inter-processor control needed, (3) 8K for 4K useable is too much overhead.

I would say -- use a fixed table for your tasks. Yes, you can "link them" if needed. What is interesting is 

that the scheduling sequence is only modified by SetTaskPrio() -- so linked lists can be disposed of

completely (just reorder TCB blocks on SetTaskPrio). This rework would save you (1) code, (2) a LOT

of data, and (3) give you core speed -- back to fully predictable worst-case performance. (Actually,

O(1) schedule is possible within the constraint of your API -- more on the API later).

Now, the core would have no further need for  about 50% of the code -- we are now down to a sub 4K

kernel, with no dynamic allocation.

We don't really want semaphores -- unless the semaphore is allocated in the task, statically. Better

choice for the Z80. (like FCBs in BDOS). Note that BDOS does NOT allocate anything! (for similar 

design reasons).

In general, a very nice project! Thank you for sharing. I take exception to the 7Mhz Z80 not being

"real-time" -- the 2Mhz 8080 certainly was (and I have code for 4Mhz Z80 that is in jet fighters

(old F18s, but they are still flying) -- kind of HAS to be real-time, and... stuff... did defense

work).

I am not sure that semaphores are that appropriate here. It forces the core to use pointers to

user space semaphore, which is ok, but... doesn't compose well for limited number of tasks

I would suggest event bits (a la OS 360) Each task could have 16 or 32 event bits. If we limit

to 32 tasks, and each task has 32 event bits, we should be covered. Then, waiting on

multiple events becomes easy. And... for example - Event Bit 0 could mean "waiting for BDOS" for each

task. "Thundering herd" is limited to 32 (by design) so not much problem. Resources need

to be pre-assigned (good thing, prevents deadlocks by analysis, AND priority inversions

are less of an issue). Note that a "broadcast" looks like this:

for task=1 to n:if task(waiting) and event then task(state)=run: clear bit task(waiting)next

which runs in O(n) time. To obtain O(1) dispatch, make task(stat)=run if task(priority) > next(priority) next = task -- or

something on those lines.

Now -- your project is designed as a teaching OS, constrained to the Z80 -- and therefore

does cover some of the common issues. My observation is that a production OS for the 8080/Z80

class machine is a bit different. Your OS beats my ideas for teaching.

Fred Weigel

 

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/is43UD_1vFA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/36f09d90-fc5b-4807-ab77-fcb613722a14n%40googlegroups.com.

[Alan Cox]

3 - Buffering is needed on serial at 115200 baud, because your scheduler cannot keep up. But... the ring buffer "saves

you" Yes, you are correct, you have 80 microseconds per character. But..

4 - At 7..8 Mhz you have 1 million instructions per second -- or 80 instruction budget. To respond to interrupt,

and schedule. So...

RC2014 is 7.37Mhz so you've got 640 clocks per character at 115200 baud (assuming 1 start, 1 stop bit). Secondly you've got 2 bytes of buffer plus the character being received (so about 2.8 characters) of internal queuing in the SIO. Thus in practice you can sustain data to a buffer if you can service the entire buffer in under about 1500 clocks. As xmodem is a data/ack/data/ack sequence you can sustain xmodem at 115200 just fine with well written SIO code and a big enough buffer even in IM1, and with a 16550A it's a walk in the park to do so. ACIA is more fun.

115200 is a very poor choice of speed for such a slow CPU but the original ACIA based design was kind of stuck with it.

Alan

[flyingbird]

Hi,

I can confirm that tbdos.as demo works successfully  on my system.

http://www.valachnet.cz/lvanek/diy/rc2014/rtm_z80

Bye,

Lumir

Dne sobota 4. září 2021 v 8:19:27 UTC+2 uživatel ladislau...@euroqst.ro napsal:

[ladislau szilagyi]

Hi Fred,

thanks for reviewing my code.

Some remarks:

1. The "buddy system" allocation algorithm IS time-bounded (see Knuth). My statistical measurements show an average of 130 micros, with 180 micros as "worst" performance.

2. Yes, you're right about the GetSIOChars. It was the only solution. But... I wonder if there is another Z80 multitasking kernel on the market capable to handle reading a 16KB HEX file while doing task switching in a tight loop (see TESTS/tswitch.as - two tasks keep Signal/Wait-ing in a continous loop, while the third reads a big .HEX file at 115200). Please give me an example of such an Z80 multitasking kernel. RTM/Z80 has an average of 160 micros task-switching time.
3. My choice for counting semaphores was influenced by my frustrating experience with RSX-11M which did have flags, not semaphores. In my opinion, counting semaphores are ideal for waiting queues. I use them for task switching, message passing, even I/O handling.

4. 32 tasks seem to me more than enough for Z80.

5. Not only SetTaskPrio affects task scheduling, see the round-robin mechanism

6. Yes, RTM/Z80 is designed for teaching multitasking. I hope it is not too constrained by this choice...

regards,

Ladislau

[Fred Weigel]

It was not the time-bound on allocation -- it was the space-bound. I haven't had time to check the OS source for allocation sizes, and made the assumption that, since a general allocator using the buddy system was implemented, that there would be such variation in block sizes. This can, with the buddy system,

lead to external fragmentation - that is, the block buddy is still in use, and a merge cannot be done. This, in turn, leads to heap exhaustion at the size div 2 point -- for 8K heap, the idea is that we are pretty safe until the heap is 1/2 full (4K).

And *that* was the issue with being "not real time". If all allocations are done right away, and no dynamic allocations then occur, your OS core IS "real time" in the sense that everything works and is time-bounded. As long as all kernel allocations are done at task startup and all tasks are created at

startup, your OS is as real-time as it gets.

I hope that makes sense...

Yes RSX11-M had event flags... for the reasons I argued (no allocations). What is interesting is that most "small" OS cores of that era used them (event bits) -- because the task control block had both the flags and wait flags -- it was easy to examine. In turn, it is easy to "swap out" an entire process -- if semaphores are in the address space that is swapped, we have problems. Which then forces us back to dynamic allocation of semaphores... which we may not want.

I agree, 32 tasks is ok! However -- I will indicate that a "task" can be viewed as a co-routine -- once that happens, the user may want... more.

See Modula-2.

I haven't had time to dig into your round-robin stuff yet. Back in the day, we produced a two-user word processor called the, um... "twin".

But, we then produced another one with 2 Z80s for one user... The "twin" modified the core OS to use round-robin. Two sets of task tables -- high

and regular. If nothing in high was ready, take regular on a round-robin basis. This allowed io service to be "high" (eg. feed the printer, disk

change, etc.) and allow user editing, etc to be "regular". Basically, two scheduling classes. Priority was assigned on task wakeup for "high"

and, frankly, ignored for round-robin. Again, this saved having to "enable or disable" the feature.

FredW

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/is43UD_1vFA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5c601e3d-0351-4128-b58c-0b8cad0454d1n%40googlegroups.com.

[ladislau szilagyi]

Hi all,

I want to thank all of you (Lumir, Bill, Tadeuz, Jay, Fred, and others...) who are testing or reviewing my system's features. 

I really appreciate it.

Turns out my choice for a group was right!

I really like the way you are keeping alive the passion for these old but wonderful machines...

regards,

Ladislau

[Tadeusz Pycio]

Hi Ladislau,

We share the same passion, it always makes me happy when we share our ideas, projects. This processor is worth it despite its old age and low performance. It was one of the last products that the customer knew everything about, down to the smallest beat of the clock, without patent trolling and misunderstood intellectual property protection. I paid for the product, not the service. That's why the Z80 will live on forever with all of us involved.

Tadeusz

[ladislau szilagyi]

Hi all,

I added the necesary interface to facilitate executing RTM/Z80 applications as .COM files, directly on RC2014's CP/M.

On the RC2014's CP/M, now it's possible to:

- build the RTM/Z80 system

- build the RTM/Z80 application

- load and run the application, as a CP/M .COM file  

This way, when CP/M runs under RC2014, the use of .HEX files is completely avoided.  

The RTM/Z80 user manual is also updated and contains an example on how to build an RTM/Z80 application on RC2014's CP/M.

Of course, if CP/M is not accessible on RC2014, the old scenario that uses .HEX files to load and run RTM/Z80 applications is still valid.

Ladislau

[flyingbird]

Hi,

there is some mess on Github: lot of files are in UPPERCASE and lowercase, e.g. BALLOC.AS and  balloc.as. Bye, Lumir

Dne úterý 21. září 2021 v 20:18:21 UTC+2 uživatel ladislau...@euroqst.ro napsal:

[ladislau szilagyi]

Sorry,

I cleaned up the mess :)

Now, the GitHub is ok.

Ladislau

[ladislau szilagyi]

Hi all,

I just released the RTM/Z80 version 2.1

I now support also the 512 KB RAM/ROM memory module (RTM/Z80 can be booted from this module, and some functions to load/store from/to the 512KB RAM were added)

The interesting news is that I have now a complete stand-alone RTM/Z80 + CP/M development environment.

I use a configuration containing: SC112(motherboard) + SC108(Z80 CPU + 32 KB EPROM containing my code + 128KB RAM) + SC110(SIO+CTC) + Digital I/O + 64MB CF card board.

After boot, the following options are displayed:

Press 0 to boot CP/M,

or 1,2,3,4 to boot an RTM/Z80 version,

or 5 to start Watson :

My current day-to-day use scenario is the following:

1. boot CP/M (BDOS loaded at DA00H, thus I have an extra 2+half KB added to the TPA area, compared to the 'traditional' RC2014 CPM which loads at D000H)

2. assemble RTM/Z80 and build the RTM/Z80 application as APP.COM (I have no more problems related to lack-of-memory at compile or assembly time !)

3. from CP/M, execute APP.COM, this will run the RTM/Z80 application

4. after the application shutdown, I boot Watson to see the results of the application run (the data left as result)

5. loop back to 1

I tested also configurations using the 32KB EPROM+128KB RAM Memory module, and the 512 KB EPROM+512 KB RAM Memory module, using the same booting options as in the case of SC108.

I updated the files on GitHub, including an updated manual.

A new CPM folder was added too, containing the "PutSys" (source and .hex) for the CPM with extended TPA size, the BDOS & BIOS sources, and the CP/M boot source.

regards,

Ladislau

[ladislau szilagyi]

Hi,

I added in the RTM/Z80 manual ( at the end of chapter "Building & running an RTM/Z80 app on RC2014") the procedure necessary to build the CP/M with larger TPA size, for those of you who use a 64MB CF and want to be able to assemble/compile large(r) source files.

Basically, it tells the story of building a custom putsys.hex file.

Ladislau 

[ladislau szilagyi]

Hi,

using the opportunity to have now my Z80AS assembler (a more performant assembler, compared to HiTech's ZAS) , I published on GitHub ( https://github.com/Laci1953/RTM-Z80/tree/main/SOURCES-Z80AS ) the RTM/Z80 source files ready to be assembled with Z80AS. 

Modifications:

The RTSYS.AS contains now the RTSYS1A + RTSYS1B + RTSYS2A + RTSYS2B files, concatenated (as in the initial version). 

All the files were updated, using TITLE, IF / THEN/ ELSE conditional assembly, instead of the old COND / ENDC, and additional PUSH_REGS & POP_REGS macros, improving readability. 

Also, BDOS.AS contains now the original Clark A. Calkins version from 1981, instead of the almost illegible format used by me in order to "survive" the ZAS assembly. 

In the RTM/Z80 files, not a single code instruction was modified, the target was only to improve usability and enhance structure.

I have tested the RTM/Z80 object code files obtained using Z80AS assembly, it works as designed (Z80AS produces object files fully compatible with the HiTech's LINK).

All functionalities & user manual remain unchanged.

Ladislau

[ladislau szilagyi]

Hi,

In RTM/Z80 I added the option of using code overlays for the 512 ROM + 512 RAM memory module.

Large RTM/Z80 apps (code up to 512 KB, dynamic memory up to 460 KB) can be executed on a RC2014 provided with the 512KB ROM + 512KB RAM memory module.

The memory is partitioned as follows:
P0=0000H – 3FFFH : partition reserved for RTM/Z80 kernel + main app task & read-only data
P1=4000H – 7FFFH : partition reserved for app tasks & read-only data (overlays, executed from ROM)
P2=8000H – BFFFH : partition reserved for RTM/Z80 read-write data & main dynamic memory
P3=C000H – FFFFH : partition reserved for RTM/Z80 extended dynamic memory

All system functions are available, called from C or assembler language source apps.

Tasks switch time is not affected, interrupts handling & I/O drivers are not affected.

The code overlays are stored on the 512KB EPROM, can be called from a CP/M .COM executable and the dynamic memory uses the 512KB RAM space.

I published the updates (source, manual, app example in TESTS/512).

Ladislau

[ladislau szilagyi]

Hi all!

Remember what Tadeusz told me last summer?

I quote: "Perhaps it is worth considering the implementation of the MMU for RTM-Z80, which will give more flexibility and scalability for this system. Several modules are available to do this (eg Spencer 512k ROM + 512k RAM Module, Karl #65a, ...)."

Eventually, I managed to implement some (limited) MMU on RTM-Z80, as Tadeusz suggested!

Thank you, Tadeusz, for the hint! I take this opportunity to express my deep admiration for the work that Tadeusz and many other Poles are doing to help Ukrainian refugees. All my respect!

Ladislau

[ladislau szilagyi]

Hi,

I published an RTM/Z80 update (new version 2.4)

In the DEMO folder, (new in v2.4): getxfile & putxfile implement the XMODEM protocol (SIO, 115200 bauds).

They can be used to move files from/to RC2014 - from/to the computer/laptop that runs the terminal (e.g. TeraTerm).

- getxfile copies files from the laptop to RC2014
- putxfile copies files from RC2014 to the laptop

Of course, you must use in TeraTerm the command : File > Transfer > XMODEM > Send or Receive, after being notified 

( you receive a message like: "...you have 30 secs to initiate sending the file via XMODEM..." )

getxfile.com & putxfile.com will be executed in CP/M; when started, RTM/Z80 is booted and a multitasking application is launched.

At exit, the SCM monitor is booted, then CP/M can be restarted.

They perform all the serial communication I/O, at 115200 bauds, on interrupts.

They are configured to be used on RC2014's provided with SC108 + SC110.

Example of use:
--------------

D>getxfile

RTM/Z80 2.3
Receive files via XMODEM
Save file as (e.g. a:myfile.txt<CR>) : d:bdosbios.as
...you have 30 secs to initiate sending the file via XMODEM...
File received & saved
Press 'y/Y' to receive another file:n

Small Computer Monitor - S3
*cpm
RC2014 CP/M BIOS 1.2 by G. Searle 2007-18

CP/M 2.2 Copyright 1979 (c) by Digital Research

A>d:
D>sdir bdosbios.as

Directory For Drive D:  User  0

    Name     Bytes   Recs   Attributes
------------ ------ ------ ------------
BDOSBIOS AS    168k   1334 Dir RW

D>z80as bdosbios.as
Z80AS Macro-Assembler V4.8

Errors: 0
Finished.

D>putxfile

RTM/Z80 2.3
Sends files via XMODEM
Send file (e.g. a:myfile.txt<CR>) : d:t.txt
...you have 30 secs to initiate receiving the file via XMODEM...
File sent
Press 'y/Y' to send another file:n

Small Computer Monitor - S3
*

[ladislau szilagyi]

Hi,

I just published a new version, v2.5.

Z80 KIO is now supported (CTC, SIO, PIO), on interrupts, and also Z80ALL is added as a configuration option.

Ladislau

[Tadeusz Pycio]

I have a question about multitasking systems for the Z80. How should the CTC->SIO interrupt priority be set or vice versa? In the first case, a higher priority is given to the dispatcher process and character loss is possible, and if we give a higher one for SIO then the task queue handling (e.g. time) can be disrupted. I have such a dilemma with MP/M.

[ladislau szilagyi]

Hi Tadeusz,

this is a difficult question, and the answer depends also on what kind of application (set of tasks) you want to execute under the multitasking system. 

There are 2 sides of the problem: hardware & software.

In the hardware setup, it is possible to set a specific priority (the interrupt daisy chain...). For example, I use the "SIO-CTC-PIO" order when programming the KIO.

But, in my opinion, the most important thing is the software-related "prioritization".

Example: In RTM/Z80, if the "serial communication" flag is selected in the configuration settings, the system is built in a specific manner ( e.g. in the Real Time clock interrupt routine, I "check" repeatedly for a possible incoming SIO character, in order to store-it quickly in the "inputs-ring-buffer" ; the same "check" is performed in all the important system routines...).

Because of this "trick", I can run my XMODEM-like RTM/Z80 applications, at 115200 bauds, without any problems (I tested this with files sized hundreds of KB, being received, on interrupts, and stored to disk on the fly ...)

Of course, in this context, it is possible for some system timers (triggered by the real time clock) to "slide" a few milliseconds (1,2,3...), but this in not so critical, because the real time clock is set to service an interrupt each 5 ms. So, in the worst case, a task will be "delayed" with up to 5 ms... that's not a critical flaw, for the Z80-class of processors. 

If the "serial communication" flag is NOT selected in the configuration settings, then this "checking" is skipped; the real time clock will trigger the requested system timers very accurately, all system routines will be executed without the overhead of "checking" for an incoming SIO char, but on the other hand, the SIO is at risk to "loose" an incoming character...

Therefore, in my opinion, there is not an "universal" , guaranteed way to handle the CTC vs SIO prioritization, it all depends on the context. 

That's why I opted to include configuration settings in RTM/Z80, to build a "custom" solution, according to the end-user preferences...

regards,

Ladislau

[Tadeusz Pycio]

Hi Ladislau,

Thank you, for this answer. Yes, the most important thing is to determine what the nature of such a system is. In my case, however, it is the clock interrupts that have to have the highest priority, as the user console service is a less important task. I have tried to use the console process to handle XMODEM transmissions and it is, in this context, a dead end. I need to solve this by building a handler process for this protocol that does not use console handlers. I think you have resolved my doubts.

[Alan Cox]

In the Fuzix case it prefers serial interrupts higher than CTC, but
that's ultimately because it's not an RTOS and has no priority timer
events so the decision is easy. On a small 8bit machine I think the
reality is you have to build for your exact use case and you have to
pull all sorts of stunts specific to the exact application to make
anything work. There isn't the CPU power or memory bandwidth to handle
conflicting high speed requirements generically.

[Tadeusz Pycio]

Hi Alan,

I'm going to try to 'cheat the system' with a FIFO buffer, but that rules out the use of the Z80 SIO. I will try to use the XR88C681, when its three bytes is not enough I will try the troublesome for IM2 mode 16C550 chip. A lot of work ahead of me.

[Alan Cox]

On Sat, 26 Aug 2023 at 00:53, Tadeusz Pycio <ta...@wp.pl> wrote:
>
> Hi Alan,
> I'm going to try to 'cheat the system' with a FIFO buffer, but that rules out the use of the Z80 SIO. I will try to use the XR88C681, when its three bytes is not enough I will try the troublesome for IM2 mode 16C550 chip. A lot of work ahead of me.

The later 16Cx50 chips go up to 64 bytes of FIFO which at high speed
is a real help.

Alternatively you design protocols that are built around the FIFO
limits. The Macintosh localtalk for example has a 3 byte header, a
time gap and then if ok the data block. There's a reason it is only 3
bytes!

[Mark T]

Is it not better to use an ft245 instead of a uart and a usb serial adapter?

[ladislau szilagyi]

Hi Tadeusz,

>  I have tried to use the console process to handle XMODEM transmissions and it is, in this context, a dead end.

>  I need to solve this by building a handler process for this protocol that does not use console handlers.

Take a look at:

- https://github.com/Laci1953/RTM-Z80/blob/main/SOURCES/xmodem.as (the xmodem protocol implementation in RTM/Z80, it uses RTM/Z80 I/O system functions and timers to handle the XMODEM protocol packets...)

- https://github.com/Laci1953/RTM-Z80/blob/main/DEMO/getxfile.c (the "xmodem receive" RTM/Z80 application, see the //comments, this is a classic implementation of several tasks, communicating via mailboxes, in order to read xmodem packs, then pass them to another task, who writes them to disk file...   )

> I'm going to try to 'cheat the system' with a FIFO buffer, but that rules out the use of the Z80 SIO. 

I use in RTM/Z80 a 256 byte round-robin buffer (SIO_buf), aligned at a multiple of 100H, to store the incoming SIO chars.

The GetSIOChars routine (from the SIO driver https://github.com/Laci1953/RTM-Z80/blob/main/SOURCES/io.as ) is being called repeatedly from various parts of the system routines, in order to "not loose" any incoming SIO char ( by storing them to SIO_buf ), 

while the _CON_RX interrupt routine and the I/O functions handle the SIO_buf using two pointers:

SIO_RP:         defs    2 ;SIO receive buffer read pointer
SIO_WP:         defs    2 ;SIO receive buffer write pointer

The access to SIO_buf, via these 2 pointers, is very fast, because the buffer is aligned at a multiple of 100H... (once loaded, you need to increment/save only the low-part of the pointer...)

If you have any questions related to this topic, please let me know...

regards,

Ladislau

[Tadeusz Pycio]

Hi Ladislau,

Indeed... the key to success is not a hardware FIFO, but a sufficiently large buffer which, in combination with handshake signals, prevents character loss. Of course, for a multi-threaded and multi-user operating system such as MP/M, the existence of a FIFO and hardware handshake support before the FIFO is full is a nice addition to protect against character loss while the dispatcher process is running. As Alan mentioned this three-byte buffer may be perfectly adequate, although here there is another risk associated with using the USB-Serial converters Mark wrote about, as being inherently packet (USB) devices they may have trouble responding to the handshake signals that occur.
I'm starting to see the light at the end of the tunnel (hopefully it's not the train that will run me down)  ;-)

[Mark T]

I was actually suggesting the FT245, not the usb to serial adapters which do seem to have a problem with handshaking on the serial interface side on some variants according to quite a few different threads. The FT245 presents a parallel interface to the target with ready signals that can easily be wired to mimic a 68B50 via a trisate buffer. Any possible overflow of the buffer seems to be handled by the usb to host pc quite well with no missing characters. As its not using a serial link there is no dependency on target system clock speed, it doesn’t matter what baud rate you set on the host pc side. There is the disadvange of it being a TSSOP28 package, but there are a few sources of breakout boards.

[ladislau szilagyi]

Hi,

I added, for Z80ALL, a new system component, the "System status display".

It shows, on the VGA screen, the dynamics of an RTM/Z80 application, in real time.

Two main topics are shown: the dynamic memory configuration (alloc/dealloc blocks), and the tasks status (active, waiting). 

All information is shown in real-time, the output to the VGA screen is done using "OUT (C),A" instructions... very fast.

See here: https://login.filesanywhere.com/fs/v.aspx?v=8c6c6a8d5c636ebdab6a , a small demo, for a RTM/Z80 test application which repeatedly allocate/deallocate buffers; the alloc/dealloc system calls were deliberately kept at a rate of 4 calls/sec, for a better visual impact ...

See also a "real" RTM/Z80 application (XMODEM getxfile) being monitored, here: https://login.filesanywhere.com/fs/v.aspx?v=8c6c6a8d5c6376bb7099 , while downloading a large file

( the system is too fast to see on the VGA screen each distinct event... but you can get an overall image on the way the system runs... ).

The "System status display" is integrated in the system, in RTM/Z80 version 2.5, using a configuration setting (SYSSTS).

Ladislau

[ladislau szilagyi]

Hi,

you may find movies showing XMODEM running under RTM/Z80,

on RC2014 here: https://login.filesanywhere.com/fs/v.aspx?v=8c6c6a8d5d6675ae9da5

on Z80ALL here: https://login.filesanywhere.com/fs/v.aspx?v=8c6c6a8d5d6676a56d9c

Ladislau

[Tadeusz Pycio]

Hi Ladislau,

Your videos motivate me to continue my work. I am currently in the process of adapting the hardware to meet the assumptions. It's interesting that I haven't received an answer to the question I once asked in another thread "was there XMODEM software under MP/M?", because I don't want to believe that this problem hasn't been solved long ago. Maybe I searched poorly.

[ladislau szilagyi]

Hi,

I added, for the RTM/Z80 Z80ALL version, support to access the VGA screen.

Tasks can now write on the VGA screen (including erasing the screen, positioning the cursor, etc. - all the VT52 ESC sequences are supported).

I tested this using a modified TETRIS, running as a task under RTM/Z80 on Z80ALL; see here: https://login.filesanywhere.com/fs/v.aspx?v=8c6c6a8d5f6775ac73a3

This RTM/Z80 VGA interface opens the possibility to implement on Z80ALL some nice CP/M board games, designed & implemented as multitasking apps... a new chapter to be explored :)

Ladislau

[ladislau szilagyi]

Hi,

I just published, here: https://github.com/Laci1953/Software-for-Z80ALL-retro-computer/tree/main/birds ,

the game 'Birds, eagle and the kite'.
It is designed for Z80ALL, as an example of a CP/M game running on a Z80 multitasking operating system (RTM/Z80).

It accepts inputs from the TeraTerm console and displays the output on the VGA screen.

The start screen:

c>birds
RTM/Z80 2.5
The game 'Birds, eagle and the kite'

By moving the kite (#), try to protect the 64 birds (v)
 from the attack of the quick eagle (V).
Each bird will try to fly higher and higher, to safety;
 reaching the top of screen, it escapes the eagle (v flashes).
The eagle will try to hunt them, by moving closer and closer.
If the eagle reaches a bird, the bird is captured (V flashes).
But, the eagle can be blocked by the kite (# flashes) and must
 go around it; it's the only chance for the poor birds!
Keys to move the kite: s=left, d=right, e=up, x=down
To change the speed at which the eagle flies, press m=faster, l=slower
 (the game starts with a lazy eagle)
Press any key to start...

(at end, a summary is typed : (e.g.) 17 birds escaped and 47 birds were captured by the eagle )

You may find a short movie showing the game in action here: https://login.filesanywhere.com/fs/v.aspx?v=8c6c6a8d60646d78b196

Thanks to the Z80ALL's 25MHz processor speed and quick VGA interface, the dynamics of the screen output is quite good ( birds fly flapping their wings... ) and the game is very challenging ( at eagle's full speed, it's difficult to move the kite enough quickly to block the eagle's movements...).

Ladislau 

[ladislau szilagyi]

Hi,

I published, for the game 'Birds, eagle and the kite', versions running on :

- RC2014 (only if provided with SC108 + SC110) , here: https://github.com/Laci1953/RC2014-CPM/tree/main/birds ( birds_RC2014_SC108_SC110.hex )
- Z80SIM, here: https://github.com/Laci1953/RTM-Z80/tree/main/DEMO ( birds_Z80SIM.hex )

You can found the source file (birds.c) in both of these folders.

Ladislau

[ladislau szilagyi]

Hi,

Yesterday I was asked by someone about how to run the BIRDS game...

Probably I neglected clarifying this...

So, you do NOT need to configure, build or install RTM/Z80 on your computer.

Just execute, from CP/M (for example, on a RC2014 provided with SC108+SC110), after downloading birds_RC2014_SC108_SC110.hex as BIRDS.HEX:

>LOAD BIRDS.HEX

>BIRDS

, then follow the instructions (extend the terminal window size to 48 rows), and hit any key.

(try to run-it at full speed - hitting repeatedly M, just to see what happens... it's quite challenging... then choose an appropriate speed)

Or, from Udo Munk's Z80SIM, (I run Z80SIM on my Windows laptop from CygWin ...), download birds_Z80SIM.hex as BIRDS.HEX, and execute:

>LOAD BIRDS.HEX

>BIRDS

How it works:

- the executable (.COM) contains an already configured RTM/Z80 plus the multitasking application (take a look at the source file, the tasks are clearly delimited...)

- when BIRDS.COM is executed, RTM/Z80 boots, then executes the application stored inside the executable.

BIRDS runs on the following environments: RC2014 (SC108+SC110), Z80ALL or Z80SIM.

If, however, you want to build the game from the sources, follow the instructions contained in the source file...

Enjoy the game...

regards,

Ladislau

[ladislau szilagyi]

Hi,

see BIRDS in action, on Z80ALL, here: https://github.com/Laci1953/RTM-Z80/blob/main/Birds.mp4

Ladislau

[Patrick Jackson]

Sorry to deviate a bit, but I just want to say I've been lurking on this project for a while and it looks extremely impressive!
I have an rc2014-like computer in front of me, I'm thinking about looking at its schematic for ports and such and then buying a blank eeprom chip and then flashing this over. Its a z180, not a z80, so a tad different.

I am on the hunt for a desktop-like experience on the z80, and I think this could be really cool!

[ladislau szilagyi]

Hi all,

for the Z80ALL version, I added to the VGA 'system status display' the reporting, at system shutdown, of the CPU time % consumed by each task.

Now, the "system status display" screen, at shutdown, looks like:

RTM/Z80 - System status display

Dynamic memory (8KB) - each * represents a block of 16 bytes
-------------------------------------------------------------------------
*************************************
*****************                                           *************



------------------------------------------------------------------------

     Tasks                          Status                       CPU%
-----------------------------------------------------------------------
     Priority(hexa)      Running Waiting

00                                            *                  01
0A                            *                                 42
20                                            *                 57

Ladislau

[RC2014-Z80]

If you wonder how it is possible to measure the CPU time % consumed by each task, well, it's only a statistical sampling procedure...

At each CTC interrupt (2.5 ms), the "ticks counter" of the current active task is incremented.

This "sampling" must be done only for a limited amount of time (roughly under 1 minute)... 

At RTM/Z80 shutdown, a sum of all accumulated "ticks" for all tasks is made, and then, for each task, a "CPU use" percentage is computed and displayed on the VGA screen.

Thanks to the Z80ALL's 25MHz Z80 speed, this sampling procedure does not affect the overall system performance.

As a conclusion, for Z80ALL, the "RTM/Z80 system status", displayed in real time during the execution of a multitasking application, is very useful for:

- assessing the dynamic memory load ( is it dangerously close to the maximum capacity? )

- viewing the task execution dynamics ( the tasks active <---> waiting switching )

- learning about the system load ( how long, in %, stays the system idle - is the % dangerously low  ? )

This way, a multitasking application can be fine-tuned, in an efficient way.

Ladislau

[RC2014-Z80]

some pictures...

[Bill Shen]

I like the idea of displaying system activities on  a easily accessible VGA display.  I wonder whether it makes sense to have second VGA port for that purpose?  Text-based VGA is inexpensive, basically a 25Mhz oscillator, inexpensive 4K dual port RAM and a small CPLD.  It can be memory mapped or IO mapped.

  Bill

[ladislau szilagyi]

Hi Bill,

I think that for Z80ALL, one VGA port is quite enough... the RTM/Z80 system activities display will be rarely used, mainly to fine tune, monitor or debug a multitasking app in its development/maintenance life cycle; the 'basic' use of the VGA is to display output from the apps/games...

Z80ALL is a fortunate case, where the I/O mapped VGA is very convenient to be used for such 'system activities display' in real time, but I wonder how to design a 'system activities display' for other Z80 homebrew computers... the serial console interface is too slow to be used!

Therefore, unfortunately, the RC2014/RCBUS based computers are at a disadvantage here... they lack a fast output interface to the terminal/screen (or, am I wrong on this?) 

Surprisingly,  in the the case of Z80SIM, used as a platform to run RTM/Z80 apps, the situation is better... I can use the I/O mapped interface to the terminal (  in Z80SIM, OUT (1),A writes a character to the screen ). However, a major issue remains: only apps that do not output text to the terminal will be monitored (otherwise, output from the app will be 'mixed' with the output of the system activities display...). One possible solution may be to 'disable' I/O to the terminal, when system activities display is active...still thinking about a convenient approach...

In the case of Z80ALL, this is not a problem because the apps can output text to the TeraTerm terminal, while the system activities display will output to the VGA screen.

Example: the pictures that I attached yesterday document the execution of a 'round robin app' test ( see source file here: https://github.com/Laci1953/RTM-Z80/blob/main/TESTS/trrb.c ).

At run time, the app wrote to the TeraTerm console the following messages:

---------------

c>trrb

RTM/Z80 2.6

 T5 counted 50000

 T3 counted 30211

 T2 counted 20084

--------------

(task T5 priority = 5, task T3 priority = 3, task T2 priority = 2)

...while the 'system activities display' produced the output seen on the pictures. So, no conflict between outputs...

Ladislau

[Bill Shen]

Hi Ladislau,
Adding 2nd VGA for Z80 is fairly easy because Z80 has 64K of I/O space while text-based VGA only needs 4K of I/O.  For memory-mapped I/O like 6502, it becomes more difficult to take another 4K of memory to display video.  For Z80 I'm thinking of VGARC which is, by default, mapped to I/O space 0x0-0x0FFF and behave very much like the video interface of Z80ALL.  In fact, Wayne Warthen has done a great job of integrating VGARC + RC2014 into RomWBW to achieve a standalone RC2014-compatible computer.  It is easy to add second VGARC (or first VGARC to Z80ALL) to RC2014 and compatibles by changing the video's base I/O address , so I was wondering whether such addition make much sense.
  Bill

[Alan Cox]

On Wed, 20 Sept 2023 at 08:52, ladislau szilagyi

<ladislau...@euroqst.ro> wrote:
>
> Hi Bill,
>
> I think that for Z80ALL, one VGA port is quite enough... the RTM/Z80 system activities display will be rarely used, mainly to fine tune, monitor or debug a multitasking app in its development/maintenance life cycle; the 'basic' use of the VGA is to display output from the apps/games...
>
> Z80ALL is a fortunate case, where the I/O mapped VGA is very convenient to be used for such 'system activities display' in real time, but I wonder how to design a 'system activities display' for other Z80 homebrew computers... the serial console interface is too slow to be used!
>
> Therefore, unfortunately, the RC2014/RCBUS based computers are at a disadvantage here... they lack a fast output interface to the terminal/screen (or, am I wrong on this?)

The propgfx card is blazing fast as a text console. Sadly limited to
40 columns and peering at the propellor code to add 80 col kind of
defeated me. It's a slow reset and font tile load at boot but then
incredibly fast, including hardware scroll. The EP9345 is a bit slower
but not a lot in text mode, and again has hardware scrolling. The
TMS9918A is slow when scrolling. Lots of option sand you can multihead
most of them too. My big rcbus machine is currently triple headed
video 8)

For serial based I/O it depends how you drive it. With the shared
memory interlink you can offload all your serial I/O to a second
processor card for example. On the Z180 you can use DMA to queue
chunks of update in the background if you had that as a specific
requirement.

[ladislau szilagyi]

Hi all,

I just updated the RTM/Z80 manual and published-it on GitHub ( https://github.com/Laci1953/RTM-Z80/blob/main/RTM-Z80%20User%20manual%20v2.6.pdf )

The current version is v2.6

Ladislau

[ladislau szilagyi]

To facilitate a more accurate tracking of the CPU time allocation, I added two new functions: 

StartSampling : starts the real-time clock "sampling" ( each real-time clock interrupt increments a counter for the current active task ) 

StopSampling : stops the "sampling"

At system shutdown, these CPU % statistics are shown on the VGA screen.

I added calls for these functions in the GETXFILE app and made a "load" test.

Running GETXFILE on Z80ALL , for a big text file, the system status display showed the following CPU allocation : 

"xmodem task" 10%

"disk file write task" 30%

"packet dispatcher task" 35%

"console driver" 1%

"idle" 24%

Therefore, at 115200 bauds, the GETXFILE app's tasks reading XMODEM packs and writing them to disk are using only 3/4 of the total CPU time ( a quarter of the CPU time is not used at all ). Better than I hoped!

This once again proves the usefulness of the system status display facility.

Ladislau