the model ii programming and other problems

[vol]

I have several questions.  Most of them are about the model II.  Sorry I have not been able to dig out the answers myself.

Is there a way to transfer data to the model II disk images?
Is there a way to transfer data to CP/M disk images?
Are there any transfer data tools for Linux somewhere? I am aware of trs80-tool but this program is still too limited and buggy.
Is it possible to dig out a Programmer's guide to TRSDOS/CPM/... for the model II on the net?

Emulator trs80gp is very capable.  It can emulate the model II very well.  But I don't know a way to transfer my code under any emulator.

Thank you

[George Phillips]

[ I think I've answered you in e-mail but will repeat here anyways since the information may be useful to others. ]

 

For TRSDOS (2 and 4) you can use the built-in utilities diskette and the IMPORT2 program.  Read the "File Import and Export" section at http://48k.ca/trs80gp.html for details.  But briefly you might do something like:

    trs80gp -m2 -td :tu2 -frehd
    .... boots, enter date, time
    IMPORT2 file.txt

For BASIC (and possibly other text input) you can use "File -> Paste" to input the clipboard text.

I don't have any utilities for CP/M but pasting text could work there (for the Model 2).  For binary data you could paste a uuencoded or base64 text file and then use a CP/M utility to convert it into binary.

The Model 2 archive https://github.com/pski/model2archive will have some TRSDOS programming information.  I think the name of it isn't obvious; something like "Owner's Manual" which includes detailed programming information like system calls along with the usual how to use the machine and TRS-DOS commands.

There may be CP/M documentation there but I'm not sure.  For the simple things any CP/M guide to system calls should work on the Model II.

You can input a new value for the PC register to get the debugger to disassemble other locations.  It's clunky but that's all there is for now.  One nice thing is that if you change the PC it can usually be changed back by "undo" (ctrl-Z).

[rietveld]

I am using a $30 Gotek .  I connected it to my Model 2.  All I do is put .DSK files onto a usb thumb drive and plug that into the Gotek.  Then just Backup from the Gotek to the physical 8 inch drive 

You can do this with TRS DOS and CP/M disks

 

 

 

Edited August 22, 2021 by rietveld

[vol]

22 hours ago, George Phillips said:

The Model 2 archive https://github.com/pski/model2archive will have some TRSDOS programming information.  I think the name of it isn't obvious; something like "Owner's Manual" which includes detailed programming information like system calls along with the usual how to use the machine and TRS-DOS commands.

Thank you so much for your very useful information.  I am a bit obsessed by the model II because it is among rare computers that have full support for the interrupt mode 2.  However I still have not been able to find any information about interrupts on the model II. It seems I checked all materials on https://github.com/pski/model2archive but found nothing that explains interrupts: sources, vectors, ...  This information is OS dependent, so TRSDOS and various CP/M may use interrupts rather differently.
It is not easy to detect an interrupt call under mode 2.  I could find out that a routine at 43b is called every 1039 ticks under TRSDOS20A - IMHO it is unusually fast, it is about 4 KHz...
TRSDOS-II Reference Manual has text "See `Programming with TRSDOS-II' for information on interrupts" but it seems that this material is lost.  

So I keep looking for any information about interrupt details on the model II.  Would anyone like to help a little?

[George Phillips]

If you use Debug -> Device Map on trs80gp it will show you the I/O port ranges of the various devices.  I suggest checking out these ones:

RW $E0 - $E3 PIO
RW $F0 - $F3 CTC
RW $F8       DMA

Those are the Zilog Z80-PIO, Z80-CTC and Z80-DMA chips.  The Zilog data sheets and other guides will describe their use.  They all use a similar sort of scheme for mode 2 interrupts.  One of the device registers is the interrupt vector the device will use.  A device will generally have more than 1 interrupt -- I think the CTC has 4, one for each channel.  In that case you can only select an interrupt vector that is a multiple of 8.  So you could set the CTC to use vectors 0,2,4,6 by programming it with vector 0.  Or 8,10,12,14 by programming it with 8.  Each interrupt vector is 2 bytes so the vector setup goes in steps of 8 for the 4 vector blocks.

 

A word of caution on using these in trs80gp.  Their emulation has been tested across a few operating systems, including Xenix which does work them pretty heavily as the Z-80 does all the I/O.  But I'm sure there are many features of the chips those operating systems do not use.  It is possible, probably even expected that the emulation will be incorrect for some aspect of the chips.  Programs that work on the hardware could fail on the emulator and vice-versa.

 

Therefore, the safest course is to look at what TRS-DOS does and do the same sort of thing in your programs.

[vol]

Thanks to your information I could make some progress.  

On 8/21/2021 at 10:05 PM, George Phillips said:

I don't have any utilities for CP/M but pasting text could work there (for the Model 2).  For binary data you could paste a uuencoded or base64 text file and then use a CP/M utility to convert it into binary.

I have found out that the best way to transfer binary data to the trs80gp emulating the model II under CP/M is to use DDT.  I use the next tiny script that produces a text for DDT that I paste into the emu.

od -v -A n -t x1 FILE.com | awk 'BEGIN {print "s100"}
{ for (i = 1; i <= NF; i++) { n++; print $i } }
END { print ".\ng0\nsave", int((n + 255)/256), "'$2'"}' > FILE.ddt

This allows me to do some timing tests.  Their results show that there is a problem: timings I get from the emulator do not quite match timings I get from my stopwatch.  I did the same tests for the emulated models I, III, and 4 - the timings are absolutely identical there.  I did my tests under Pickles and Trout CP/M, and under Aton CP/M.  There may be several options:

1) documentation about these OS is not correct.  It claims that these systems use 10 ms (100 Hz) timers, maybe the frequency is actually slightly less.  I use documented function calls to get data from timers;

2) trs80gp is not 100% accurate emulating the CTC;

3) ...

I am going to publish my results soon.

On 8/22/2021 at 9:08 PM, George Phillips said:

Therefore, the safest course is to look at what TRS-DOS does and do the same sort of thing in your programs.

It is sad that I still can't find a way to use a timer under TRSDOS20A.  I don't want to program hardware because it may corrupt the system. Maybe I can find a way to use the system interrupt handler at 43bh but IMHO it would be better to do these things in a more documented and less hacky way.

Edited August 24, 2021 by vol

[George Phillips]

The timing of the Z-80 for the Model II will be highly accurate but it is definitely safe to say the CTC and other chips have never been directly compared against the real hardware.

 

But we'd need to know what timing is used by Pickles and Trout CP/M and Aton CP/M.  There is a 30 Hz interrupt based off the display chip which, although it is too low resolution, might have been used in some way to approximate 100 Hz timing.

 

The code to your timing tests would be a great help in sorting out the problem.  I could first use it to determine what the source of timing is.  Then we might be able to deduce where trs80gp's timing is off.  Or it may be ambiguous as sometimes the correct behavior is not self-evident.  In which case I could find someone with real hardware to run the test and give a definitive reference point.

[vol]

9 hours ago, George Phillips said:

The timing of the Z-80 for the Model II will be highly accurate but it is definitely safe to say the CTC and other chips have never been directly compared against the real hardware.

 

But we'd need to know what timing is used by Pickles and Trout CP/M and Aton CP/M.  There is a 30 Hz interrupt based off the display chip which, although it is too low resolution, might have been used in some way to approximate 100 Hz timing.

 

The code to your timing tests would be a great help in sorting out the problem.  I could first use it to determine what the source of timing is.  Then we might be able to deduce where trs80gp's timing is off.  Or it may be ambiguous as sometimes the correct behavior is not self-evident.  In which case I could find someone with real hardware to run the test and give a definitive reference point.

Thank you very much.  I've just started a new thread about the model II timings... I doubt that PM and Aton CP/M use 30 Hz frequency, IMHO they rather use the CTC but I am not 100% sure.

Edited August 26, 2021 by vol