George Phillips

One tiny bug left. The "Press Space" message that appears at the end of the game is scrambled if lower case isn't available. Tested it with trs80gp -m1 -nlc ttris3.cmd

Here you go. I used trld ttrs2a.cmd ttrs2a.lcas to do the conversion http://48k.ca/trld.html The name for SYSTEM is TTRIS2 but, as always, you can just give the first letter T to the ?* prompt. Running it on the Model 1 I noticed a small bug in that the screen is cleared with 0's which end up displaying as @ signs. I didn't think to try it on a Model 1. As penance I patched the code to clear with character 128 hence the ttris2a name. ttris2a.cas ttris2a.cmd

Thanks; works nicely now under TRS-DOS. You can use lower-case in messages which will work fine on the Model III and most Model I's. However, earlier Model I's did not have lower-case and need a little bit of code to handle the conversion. Their video memory only had 7 bits per byte! Here's a little code fragment that will write a character to the screen and automatically uppercase it if necessary: ; HL pointing to screen memory, A is character to display ld (hl),a cp (hl) jr z,ok res 5,(hl) ok: Of course, you could do a single test at the start of the program and uppercase all messages if the machine doesn't support lower-case.

Nicely done. Change the ORG from $4A00 to $5200 so it'll run under TRS-DOS and it'll work fine on a real machine. TRS-80 users are likely to expect the arrow keys for control rather than WASD.

You had me fooled for a bit but when I got to the VCF PNW link I figured something was up. I recommend this one: http://cococrew.org/cococrew-podcast-93.html Which was a bit tough to find as the link at the top of the index page points to episode 92. It's all for the best; this sort of mental exercise keeps me on my toes.

There was a version of CP/M that ran on the Model 1 but it wasn't terribly compatible as the first 16K of memory was not RAM as in normal CP/M systems. The Omikron mapper added bank switching so it could run CP/M programs without them having to be modified. The Omikron board plugs into the Z-80 socket and the Z-80 is put onto the board itself. The mapper literally interposes itself between the Z-80 and the rest of the computer to implement the bank switching. You could unplug the board, pull the Z-80 off the board and put it back into the socket but no real need to do so as they set things up so that the machine will still work as a stock TRS-80. You may find the manual of some help: https://prof-80.fr/images/Carte_CP-m/M1_OMIKRON/OmikronMapper.pdf

Polaris for the Colour Computer uses it very effectively. It's a missile command clone and maps the joystick position directly to the screen giving the fast movement needed to launch effective counter-missile strikes. It doesn't use the button but has you use 3 adjacent keys on the keyboard to pick which missile base to fire from. Made it very much like the arcade. Unless you're talking about the PC clone side of things and this doesn't count.

A model II 8" disk has 26 sectors of 256 bytes each per track and spins at 360 RPM. 360 RPM is 6 RPS. So an entire track of 6,656 bytes could be read 6 times in a second for a data rate of 39,936 bytes/second. The low-level data rate for the system is 16 microseconds/byte or 62,600 kB/second. The Model III low level data rate is 250,000 bits/second or 31,250 bytes/second. With 18 sectors per track at 300 RPM you get a practical limit of 23,040 bytes/second. For anyone who's interested, this explains how the data transfer rate of the 1541 disk drive was determined: https://www.youtube.com/watch?v=_1jXExwse08&t=1903s The serial I/O chip could do a bit every microsecond but was flawed so the transfer speed was reduced to 1 bit every 20 microseconds. However, the video display on the C-64 could steal up to 40 microseconds from the 6510 so the transfer speed was reduced to 1 bit every 60 microseconds.

At one time the Model 16 (or was it 6000?) was biggest installed base of Unix machines. It being part of the Model II line I'd say it was a market success. Only half of your requirements but something that should be better well known.

I took the more colloquial meaning along the lines of "we've got a winner on our hands". That is, a product that will sell well and generally be a success for the company. As opposed to a product that doesn't sell, fades away quickly and may even lose a company money. For instance, in that sense the Apple ][ was a winner while the Apple /// was not. What do you mean by winner? In a more sports-oriented sense of the word I'd say only the IBM PC was a winner. It and the Mac are the only microcomputers produced today and the PC has a vastly greater market share than the Mac. PC's also grew out of the microcomputer market to destroy the workstation market. Sun and DEC machines are not winners, just temporarily successful.

I'm going to straight-up copy from pski's post in another thread just to nip a potential misconception in the bud. ---- The Model II line was far, far from a failure. The Model II family ran for 10 years. Of course it did not sell as many units as the smaller TRS-80s or Apples or Commodores. This was a workstation class machine meant for medium sized businesses and serious technical environments. In one year, the Model 16B was the most popular Unix based workstation by sales across the industry! The 8" floppy drives offered multiple times the storage capacity of comparable 5.25 drives for most of the lifetime of the series. This was a critical feature for data intensive workloads for which the machine was intended. Of course, by 1988 it was hopelessly outdated. This was a time of rapid progress in the microcomputer industry. The Model II line was a success by any measure. ----

I looked into the Pickles&Trout version since it does a special purpose CALL to $40 to read the timer. I put a breakpoint there and ran the pi program. Stepping through routine I saw it simply reads a multi-byte value from $EA74. I put a write breakpoint on that location. Using the tracing options showed that the interrupt comes from CTC channel 3 (CTC3). And in the trace the interrupt occurred about 40,000 T-States after the previous one. Which is what you'd expect for a 100 Hz interrupt with the Z-80 running at 4 MHz. Leaving the write breakpoint in place I can set the T-State counter to 0 in the debugger (the T field under PC). Then when I hit go it will run to the next breakpoint. Doing this a few times I see the T-States between interrupts to vary a bit from 39930 to 39942 or so. I've not done a trace to see what values are written to the CTC but it seems fair to assume they'd be aiming to see 40,000 T-States between interrupts. I'd expect a little bit of slop in the values reported by the debugger since an interrupt does have to wait for the current instruction to finish. That can't account for coming up 60 to 70 T-States short. I do recall the Z-80 support chips have a tendency to need "off by 1" values (like the DMA transfer size). That could possibly explain the difference. While not exact it is only a 0.175% difference. And if anything the clock should be running a bit fast, not slower since the interrupts appear to be slightly faster than they should be. From a virtual perspective (i.e., comparing Z-80 to CTC timing) it looks pretty close to correct. trs80gp synchronizes with real time by waiting every frame for a 1/60th of a second of real time to pass. That timing isn't super perfect but I don't think it is the source of the discrepancy as the timing for Model 4 works fine. However, the model 2 emulation may have a bit of a disagreement between the real time interval it waits for and how many cycles the machine actually runs for. It's a bit trickier since a video frame on the Model II can vary depending on how the display chip (CRTC) is programmed. I don't think the real time wait is exact so I'd say that where the disagreement between internal timing and the stopwatch arises. I'll endeavor to improve the real time timing of trs80gp in Model II mode, but my trs80gp TODO list is pretty long so I'm afraid I can't say when I'll get around to it. So, for the moment it seems the the self-reported timings are pretty close and you can rely on them. This is nice since if you run in turbo mode you'll get the same timing results from trs80gp which is great for blasting through benchmarks. It would be, of course, still interesting to see the self-reported and wall-clock timings on a real machine.

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.

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.

[ 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).