Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

63 Excellent

About vol

  • Rank
    Chopper Commander

Profile Information

  • Interests
    IT, math, history

Recent Profile Visitors

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

  1. Thank you. I like trs80gp very much, IMHO the idea to keep the base disks inside emulator is really fantastic. Aton CP/M has also a special call to read the system timer, this call is described in the manual (page 30 in the pdf-file). I use this call in my program. It is still interesting why Aton CP/M timing discrepancy is much larger than PT CP/M. I still have tiny doubts about this. I can't still understand how can the model II be slightly faster than the model 4p? Maybe it is because of more frequent interrupt rate under TRSDOS62? Some results from real hardware can really help me much. Anyway I am gathering timings for 100, 1000, and 3000 pi-digits computation. Under Pickles and Trout CP/M using trs80gp, I got 100 - 1.62 s 1000 - 146.65 s 3000 - 1313.34 s However we know that the emu is not 100% accurate for the model II timings...
  2. 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.
  3. I have run several timing tests. I used a calculator program that computes digits of the number pi. I let it compute 1000 digits under trs80gp. Results are the next: the model II, PT CP/M the model II, Aton CP/M the model 4, TRSDOS62 the model 4p, TRSDOS62 You can notice that the model 4/4p shows equal timings from the emu and from my stopwatch. The stopwatch timings are a bit greater because of the natural delay for a human reaction. However timings from the model II show noticeable difference between the emu and stopwatch results. This difference is much greater for Aton CP/M than for PT CP/M. The PM CP/M manual claims that accuracy of timer must be very high (higher than 99.9%) but we have about 2.4% difference. Aton CP/M always show the current time in the top-right corner of a display but my tests show that this doesn't affect the timing difference in a noticeable way. The results also show that the model II is faster than the model 4p and that looks rather implausible because the model II uses 4 MHz clock and the model 4p uses 4.06 MHz. Would anyone like to try running the calculator on real hardware? It can help to find out the truth. I have attached a zip-archive which contains the programs to run. I clear the screen with CLS before the calculator invocation - this makes things slightly faster. Thank you in advance. pitest.zip
  4. Thanks to your information I could make some progress. 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. 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.
  5. 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?
  6. 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
  7. I have played with a tiny program 10 DIM A$(1000) 20 PRINT ADR(a$) After RUN I get 2091, then after PRINT ADR(A$) I get 2095, but after GOTO 20 I get 2098. All these results are fixed. The next PRINT gives 2095 again, the next GOTO20 - 2098. Is it possible to explain these results? It is also interesting to know is it possible to write a Basic program that doesn't move its array just after GOTO or PRINT? Thank you.
  8. It is well known that there was a muLisp implementation for the Z80 card - it is available on apple.asimov.net. However I have not been able to find muLisp for the 6502. It seems that it could be released too according to this document... Thank you.
  9. Maybe it can be interesting that Lightningsort for the C64 is buggy - details are here - this subtle bug is caused by the improper use of zp locations, so Lightningsort implementations for the Apple II and IBM PC may be correct. Anyway we just got that the count of known quicksort implementations for the 6502 has decremented to 3: Atari Supersort (1981), C64 Ultrasort (1983), and C64/C+4 Enhancedsort (2021).
  10. Of course, I even contributed some algorithms there.
  11. Thank you very much for these links. I have checked the ATX Supersort. This year is the 40th anniversary of the date when Supersort was published. This program appeared 3 years before the best C64 sorting program (Lightningsort) was published and it was about 10-15% faster! The latter is caused by insertionsort optimization. I thought I could make much faster code but I was able to get only small advantage. However my sort routine is never quadratic, so for some rare cases it can be much faster. Supersort is quadratic for ordered or nearly ordered data. I have to confess I didn't expect that old software from 1981 can be so good. I only miss good programs that allow us to test a large array of strings. Therefore I wrote two programs to fill this gap, TSORT2 and TSORT3 for Supersort rev 2 and 3 respectively. I attached them to this post. Just boot from a proper Supersort disk and type ENTER"drive:TSORT2.LST" or ENTER"drive:TSORT3.LST". tsort.zip
  12. I has been able to decipher, test, and improve Ultrasort and Lightningsort that were published in Compute 40 and 52. The latter issue contains variants for the Commodore 64, VIC-20, Apple II, and IBM PC. However there is no variant for the Atari 800. I can think that the author just was not able to conceive the way which requires for the work with Atari Basic strings. I am also less familiar with the Atari 8-bit architecture than the Commodore. So I could make only a program for the C64. The results are here If somebody wants to port the program to the Atari I am ready to provide any help. Do you know where can I get it?
  13. You just tell me how to write my program! It is funny. You can also say that a fish must look like a mouse. Better try to make code for pi-spigot faster at first. Sorry but I have also to stop replying to your strange claims because you don't read my responses to them. I repeated my points several times... But you ignored most of them.
  14. What am I claiming? What is my approach? Would you like to clarify your point? I have never said that I know the Atari ST family very well. So I missed your point about my very low knowledge. It seems like the use of a label. Why should the results have deviations less than 1%? It is impossible for some architectures. Sorry but I have to repeat this program is not just a math test. It is an optimized multiplatform calculator. So it MUST print because it is a calculator. Why do you insists that "Saying that printing time is excluded from test time - no way sir". It is quite easy to prove that your point is not correct. Just set IO=0 in the sources, compile and run. This gives you almost the same results, the deviation is less than 1% for the Atari ST. Please provide exact numbers if you want to continue your criticism. And I don't still understand why do you use rather unfriendly phrases like "I'm sick of this attitude" - I am a professional programmer, just let us discuss things. What can change the fact that "1 character print can be in much less time" for the results? Would you like to be less cryptic? It seems that you don't want to have a real discussion. It is your right but you attacked my project and I had to reply. BTW I must say thank you to people who helped me: Darklord, moulinaie, MasterMotorola, mdivancic. Sorry I don't understand what did cause the change in attitude.
  15. I wrote afore that those results are very unusual. Results from the Falcon show only 1% difference. Anyway I am still baffled by your position. I am just gathering data. What do you mean in your phrase "I don’t get up tight and took no offense by what you posted"? It sounds weird for me. I am just thankful to you because of your help. I assume that a user picks up the best performance screen mode because otherwise we get provocative results. I publish them and people will blame me that I show the Atari ST series in the wrong color. And we have a benchmark, a test for the performance - it is quite natural to get its maximum. I just asked for help. If you are not interested you just ignore this request. Your CaTTamaran results are very interesting. I am going to start a new thread about them. You know the Amiga results show that the PI-ST30 main loop is 4 cycles faster than the PI-ST main loop. But your results show no difference. I can't understand how this is possible. Some people called me an Atari troll. You know that the Amiga character output routine is slower that this routine for the Atari ST series. The Amiga WB doesn't have two-color mode, so all tests for this computer were done under the standard 4 colors.
  • Create New...