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.