Jump to content

George Phillips

Members
  • Content Count

    66
  • Joined

  • Last visited

Community Reputation

44 Excellent

About George Phillips

  • Rank
    Star Raider

Contact / Social Media

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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. ----
  4. 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.
  5. 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.
  6. 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.
  7. [ 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).
  8. I don't actually know; something from wherever I got the original from. Hard to imagine it is necessary. For now, it'll reamain another little loose end.
  9. The built in LS-DOS image (-ld) will be equivalent. It has the latest date patches. I'd imagine the ROM is identical, too. But I can understand wanting to be explicitly the same. The Model 4 Z-80 was effectively slower when it first came out due to the wait states. It's hard to pin down exactly how much as it made instructions 2 T-States (or cycles) longer. Z-80 instructions can be anywhere from 4 to 23 T-States long. If we assume an average of 8 T-States then a later Model 4 with no wait states will be 1.25 times faster. Pretty hard to notice in most operations. You could time a long FOR/NEXT loop on your Model 4 and see which of the -m4[abc] setups comes closest to that time. Or you could run trsvid (http://48k.ca/trsvid.html) which will report your CPU as slow/medium/fast for -m4a, -m4b and -m4c respectively. It will run without a FreHD. In fact, all it will do is print out the machine report.
  10. It means the computer was booted with a data diskette inserted. That's a diskette that doesn't have the operating system installed but does have a boot block that prints "NO SYS". It's a good sign that the floppy drive works.
  11. There's definitely something going on here, the trick is to quantify it and eliminate the bug. "Typing fast" is a little hard to judge and whether or not keys are dropped depends on the skill of the typist. I found this sequence highlights the differences: Hold the 'U" key. Press 'I' and 'O' simultaneously. In trs80gp the 'O' will almost always be dropped. But I can confirm the 'O' key is down not only because I'm holding it but also because the software keyboard shows it down (in other words, the emulator has been given all the key switch changes). There is some need to be careful with that because it doesn't take too many simultaneous key presses for your average PC keyboard to ignore keys. On my Model I in Level II ROM BASIC the 'O' will sometimes drop but quite rarely. My guess is that the 'O' drops when the 'I' and 'O' are both seen down at the same time by the ROM keyboard scanning routine. It'll see the 'I', send it for output and be done. But it has recorded 'O' as being down so it ignores it on the next pass thinking it has been processed. If the keyboard is scanned more than 60 times a second then on a real machine the difference between the 'I' and 'O' press times will need to be very small. But since trs80gp only updates the keyboard once per frame it is easier to make the keys appear to press simultaneously. It is possible that somewhere along the line from keyboard to the emulator the timing of key presses becomes even more quantized. I'll have to see if there is better timing available or if there's some way to separate the key presses in time without fudging things too much.
  12. I've wondered about this myself. Level I will definitely have a limited typing speed as the ROM doesn't implement "N-key rollover". Which means that a key won't be recognized if another key is held down at the same time. And when one is typing quickly the key presses definitely overlap. Comparing against my Model I the keyboard input seems to be about the same as trs80gp. Might be a little clunkier but feels like it roughly the same. Level II is definitely substantially better than Level I which seems different from what you're reporting. I'm trying this out on Windows. What platform do you run the emulator on?
  13. Some time after seeing the TRS-80 in Radio Shack our high school business teacher bought a Model I which we used extensively as part of an informal computer club. Then my brother and I bought a Model III. From the US because it wasn't going to be available in Canada for a while. So I bought a Model III in the US for a very specific reason. I'm glad to hear it has balanced out.
  14. I saw a Model I in a Radio Shack about an hour's drive away from our town which was too small to have a Radio Shack. I don't remember exactly when, but I think either 1978 or 79. It was running and the manual was there; I think they encouraged you to try it. Typed in about the simplest possible BASIC program: 10 INPUT"WHAT IS YOUR NAME";A$ 20 PRINT"HELLO, ";A$ I was transfixed. I'd seen calculators and heard of computers but this ability to record letters and spit them back out at you was something I'd never seen before. I also remember at some point, perhaps a later trip, typing in the entire Lunar Lander program from the back of the Level II manual. Another fascinating experience for a 13 year old.
×
×
  • Create New...