Jump to content
IGNORED

I need data from the real Tandy 100 or 102


vol

Recommended Posts

Would anyone like to help me to get data about the Tandy 100/102 hardware?  VirtualT emulator is not very accurate and I need information about the Tandy 100/102 exact timings. Please run the attached program three times, for 100, 1000, and 3000 digits.  It can take about 40 minutes for 3000 digits.  Program PINT.BA prints timings in the end.  This Basic program loads ML-code (capint.co) and runs it.  Please send me those printed three numbers.  Thank you very much in advance.

tandy100-time.zip

  • Like 1
Link to comment
Share on other sites

I tried running your program, but I'm afraid I had no luck.

 

I did a CALL 63012 on my (very newly obtained) REX#, which gave me REXMGR, and I then ran CALL 63012 again so REX would give me TS-DOS. I then removed the REXMGR menu hook with Ctrl-X, and KILLed REXMGR itself in case it might interfere with the .CO file (I also tried without removing those things first).

 

I then ran TS-DOS, with LaddieAlpha running on a PC, and downloaded your files from the expanded .zip file: PINT.BA and CAPINT.CO via TS-DOS.

 

I tried a few variations of this a few times, starting from a mostly-empty RAM filesystem (just a couple of small BASIC files; the last time I tried I removed those BASIC files first for no particular reason). Every time, the first time I would run PINT.BA it would fail with "OM Error" on line 30, not sure why. When I would run it a second time, it would proceed and ask me how many digits of pi, but when I run it with, say, 8 or 20 digits, it would churn for a while, then draw black lines on the screen, and hang until I would press the reset button on the back for a warm reboot.

 

I've got photos of the screen here: https://photos.app.goo.gl/KBHa8iA1oRwGDNQ48

 

This was on a Model 100, with the REX# installed in the Option ROM slot.

  • Like 1
Link to comment
Share on other sites

Looking at the raw memory for the FS directory, I see that CAPINT.CO is installed to address (decimal) 33,707, while TS-DOS's start location is 33,106. I have my doubts that all of TS-DOS fits into just 601 bytes, so perhaps memory contention is the culprit. Unfortunately, I don't know an easy way to get your .CO file onto my Model 100 without using TS-DOS, without my rigging something up for the purpose, which is more time than I'm prepared to invest. Perhaps if you want to create a BASIC program whose function is to create the CAPINT.CO file (as seems to be a common way to distribute machine language binaries)? Then I could download both BASIC programs, unload TS-DOS and REXMGR, and then presumably run the BASIC program to install the .CO file.

  • Like 2
Link to comment
Share on other sites

17 hours ago, micahcowan said:

Looking at the raw memory for the FS directory, I see that CAPINT.CO is installed to address (decimal) 33,707, while TS-DOS's start location is 33,106. I have my doubts that all of TS-DOS fits into just 601 bytes, so perhaps memory contention is the culprit. Unfortunately, I don't know an easy way to get your .CO file onto my Model 100 without using TS-DOS, without my rigging something up for the purpose, which is more time than I'm prepared to invest. Perhaps if you want to create a BASIC program whose function is to create the CAPINT.CO file (as seems to be a common way to distribute machine language binaries)? Then I could download both BASIC programs, unload TS-DOS and REXMGR, and then presumably run the BASIC program to install the .CO file.

Thank you very much. Sorry it is almost impossible for me to make such a Basic-program which should be able to relocate itself.  CAPINT.CO assumes that it is placed at $8d00 address.  Would you like to inform me about the start address of the RAM-disk on your system?  I can change this address then and make a program suitable for your extended Tandy 100.

I can't understand why you have mentioned 33,707 ($83ab) address.  First bytes of CAPINT.CO are $00 $8d.  It seems that it is just placed at the first available RAM-disk location because $8d00 is occupied.

BTW for 100 digits, the program runs about a second.  For 4 or 8 digits, it runs almost instantly.

Link to comment
Share on other sites

15 hours ago, vol said:

Thank you very much. Sorry it is almost impossible for me to make such a Basic-program which should be able to relocate itself.  CAPINT.CO assumes that it is placed at $8d00 address.  Would you like to inform me about the start address of the RAM-disk on your system?  I can change this address then and make a program suitable for your extended Tandy 100.

I can't understand why you have mentioned 33,707 ($83ab) address.  First bytes of CAPINT.CO are $00 $8d.  It seems that it is just placed at the first available RAM-disk location because $8d00 is occupied.

BTW for 100 digits, the program runs about a second.  For 4 or 8 digits, it runs almost instantly.

 

Yeah, I later saw the $8d00 and wondered at the 33,707 address. There is a high likelihood my testing was being interfered with by a present bug in REX#, a fix for which is currently being actively tested. I suspect the file system's entry was corrupted/pointed to an inappropriate place, and that would be why I experienced my issues.

 

I didn't mean that the BASIC program should create a relocatable file - most such BASIC programs that I've seen, simply set HIMEM appropriately, copy the bytes to the expected location (in your case $8d00), and then SAVEM it. I didn't want BASIC so it'd be relocatable - I wanted BASIC so that I could clear all other files out that might collide with it, and _then_ create the .CO file (without even having TS-DOS installed to do it). However, this may not be necessary, as I think no collision should actually be happening between these files when the filesystem is intact.

 

There is a file, CHANGE.BA, at the M100SIG Compuserve library (the filename is .BA, but its contents are untokenized ASCII, as all other files there are - rename it to CHANGE.DO if you're transferring via TS-DOS or the like; not sure what your emulator will prefer). This program can do what I need - I think you'd just select CAPINT.CO and run the ">Hex" command on it, and then attach the resulting .DO file here; it may make it easier for me to ensure I'm testing what you actually created.

  • Like 1
Link to comment
Share on other sites

I think another problem I'm encountering is that PINT doesn't work properly. As I noted in my first post, it produces an "OM Error" on line 30 the first time I run it, and then afterward proceeds to ask me for how many digits. But line 30 is where the .CO file would get LOADM'd, and since the CLEAR happens before that, the next time I run, line 10 will see HIMEM<40000 and assume everything is installed correctly - so I think it never is installed correctly, which would definitely explain why I get weirdness.

 

CLEARing to HIMEM-FRE(0) can't be right, can it? That will use literally all available memory, which probably explains why LOADM triggers "OM Error" immediately after - it must have needed some of that! ...Also it looks like line 20 pokes some things into memory, before the CLEAR has happened (so we don't own it yet) - is this certain to be safe? I suppose if no strings are being allocated, maybe. I don't know much at that level of detail, but it makes me uncomfortable. :)

  • Like 1
Link to comment
Share on other sites

16 hours ago, micahcowan said:

I think another problem I'm encountering is that PINT doesn't work properly. As I noted in my first post, it produces an "OM Error" on line 30 the first time I run it, and then afterward proceeds to ask me for how many digits. But line 30 is where the .CO file would get LOADM'd, and since the CLEAR happens before that, the next time I run, line 10 will see HIMEM<40000 and assume everything is installed correctly - so I think it never is installed correctly, which would definitely explain why I get weirdness.

 

CLEARing to HIMEM-FRE(0) can't be right, can it? That will use literally all available memory, which probably explains why LOADM triggers "OM Error" immediately after - it must have needed some of that! ...Also it looks like line 20 pokes some things into memory, before the CLEAR has happened (so we don't own it yet) - is this certain to be safe? I suppose if no strings are being allocated, maybe. I don't know much at that level of detail, but it makes me uncomfortable. :)

Thank you very much again.  I use VirtualT emu.  I have got CHANGE.BA - BTW thank you for the link to this very good library.  I have tried to run it but I got a failure. :( Look at screenshots.tandy-100.thumb.png.cdd26f8ad16b025a3202dcec0ed23c13.pngtandy-100-2.thumb.png.20e066084ebd04cb1624ce38a2f096dd.png

HIMEM-FRE(0) should work fine because it leaves 256 bytes of memory dedicated for text strings.  A man helped with running PI.BA on his Tandy-100 about a year ago.  However later, he replaced the 8085 with the Z80 in his machine.  This change has made his Tandy-100 unsuitable for my tests. :(
The POKEs should work fine too.  They just preserves the value of F-variable.  It is necessary because CLEAR deletes all variables.
I have rebuilt the program so the binary part is started at $9200 now.  I got this number analyzing your screenshots.  I almost sure that this must fix the problem.  I have attached a new arhive.  All sources are available at https://github.com/litwr2/rosetta-pi-spigot/tree/master/tandy-100
I have also prepared detailed instructions:
1. Put CALCPI.CO into the RAM-disk
2. CLEAR0,HIMEM-FRE(0)
3. LOADM"CALCPI
4. CALL37376  -- this must produce 100 digits of the pi number, if it is ok then it is possible to do the next steps
5. Reset, remove all files from RAM-disk
6. Put CAPINT.CO and PINT.BA into the RAM-disk (`pint.ba' maybe used instead of PINT.BA, `pint.ba' is in ASCII)
7. LOAD"PINT":RUN  -- or just start with PINT.BA from the menu
8. Get a timing for 100 digits (it is interesting to run the program several times for 100 digits to get the timings difference)
9. Get a timing for 1000 digits
10. Get a timing for 3000 digits (a screenshot would be good!)
11. Reset, remove all files from RAM-disk
12. (Optional) Put CALCPI.CO and PI.BA into the RAM-disk (`pi.ba' maybe used instead of PINT.BA, `pi.ba' is in ASCII)
13. (Optional) Start PI.BA
14. (Optional) Get a timing for 100 digits
15. (Optional) Get a timing for 1000 digits
All optional steps can be skipped.  They  can only help with result verification.  If the ML program collides with the Basic program the latter should print "ERR".  If I moved the ML-code too far and this reduces space for digits the program after its first run must print "BAD".

BTW do you know a way do not print a space after a number? I would like to print "77)" and I can't!  I always get "77 )" :( I use PRINT 77")".  IMHO PRINT USING can't help too. :( I can only hope that there should be a special trick to do this.
Thank you.

pi-tandy-100-at9200.zip

Link to comment
Share on other sites

19 hours ago, vol said:

BTW do you know a way do not print a space after a number? I would like to print "77)" and I can't!  I always get "77 )" :( I use PRINT 77")".  IMHO PRINT USING can't help too. :( I can only hope that there should be a special trick to do this.

I've found that ? STR$(77)")" will print without the spaces. But of course you'd have to give yourself back some string space first, as your CLEAR 0 removes it. :)

 

For N > 0, you can count the number of digits N has with INT(LOG(N)/LOG(10))+1. That's fairly expensive, computationally. But you could use that together with STRING$(X,"#") and PRINT USING.

 

Finally, you could roll your own number printer. :) 

  • Like 1
Link to comment
Share on other sites

I get "BAD" printed first time I run it, before it gives the version string or prompts me for numbers of digits. However, I think the logic of your "BAD" test is reversed...? It fails if H (=HIMEM-FRE(0)) is LESS than your limit (0x9200-255, = 37376), which would mean you have MORE memory set aside than you need, and not less - doesn't it?

 

Anyway, assuming I can proceed, I got 3.0625 for 100 digits, and 281.9609375 for 1000 digits. I then ran 100 digits again and got a slightly higher value of 3.06640625, and then ran 100 digits one more time and it was back at 3.0625. Could be interrupt or other timing interference I guess? Or maybe there's longer cleanup when the previous run was for a higher number? Anyway I figure that size of discrepancy probably isn't of interest to you.

 

Currently running for 3000 digits, I'll update with that later. I added a 160 BEEP:BEEP:BEEP:BEEP:BEEP to grab my attention once the run is done, heh. Especially since I'm running the laptop off battery. ...Hm, I forgot to turn off sleep, guess that means the laptop's shutting off as soon as the program's done. Hope the display keeps the number when I turn it back on...

 

Edit: The run for 3000 digits was 2529.4140625. I managed to keep the laptop on by hitting some keys for the input buffer to hold onto. :) 

Edited by micahcowan
results update
  • Like 1
Link to comment
Share on other sites

 

One straightforward solution I've missed is to print the number, and then separately use PRINT @n,... to print starting 1 character position before the current one, using CSRLIN and POS(0) to determine where that is. PRINT 77; : PRINT @(40*CSRLIN + POS(0) - 1), ")"

 

On 11/30/2020 at 3:13 AM, micahcowan said:

I've found that ? STR$(77)")" will print without the spaces. But of course you'd have to give yourself back some string space first, as your CLEAR 0 removes it. :)

 

For N > 0, you can count the number of digits N has with INT(LOG(N)/LOG(10))+1. That's fairly expensive, computationally. But you could use that together with STRING$(X,"#") and PRINT USING.

 

Finally, you could roll your own number printer. :) 

 

  • Like 1
Link to comment
Share on other sites

On 12/1/2020 at 11:28 AM, micahcowan said:

I get "BAD" printed first time I run it, before it gives the version string or prompts me for numbers of digits. However, I think the logic of your "BAD" test is reversed...? It fails if H (=HIMEM-FRE(0)) is LESS than your limit (0x9200-255, = 37376), which would mean you have MORE memory set aside than you need, and not less - doesn't it?

Word "BAD" is printed if Basic has more than 256 bytes free memory.  It means that we can relocate the binary code lower and get more digits of the pi.  It is good that the program has enough memory for BEEPs insertion, the original version has no enough room for any addition.

Thank you very much for your results - you can see the whole picture now - here.

Thank you for the idea with PRINT@. Maybe I will use it with v3 of my π-calculator.

BTW a man who earlier helped me with his Tandy-100 used just COM-port connection, he didn't have TS-DOS.

Edited by vol
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...