Geneve 9640 benchmarks

[Geneve 9640 benchmarks]

13 hours ago, InsaneMultitasker said:

Very cool   I'm interested in seeing the program code if you are willing to post it at a future date.

Thank you!  The sources of my programs are open, a link is provided at the bottom of the table page.  The direct link is here.

[Geneve 9640 benchmarks]

On 4/10/2021 at 11:51 AM, mizapf said:

What exactly do you believe to be wrong on Ninerpedia?

It seems that this page would be slightly corrected.  I discovered that range >A000-BFFF actually uses two pages (>EF and >31) when the Geneve is in GPL mode, for instance under XB.  These pages are constantly switching in this mode.

[Geneve 9640 benchmarks]

The pi calculator for MDOS is ready.  Tables are updated.  The results

 

show that the Geneve 9640 almost caught up with the Amiga 500 and could beat the powerful 32-bit [email protected]!  However we know that MAME is slightly faster than real hardware.  So, please, if you have a real Geneve9640, run PI-EXE for me. pi.zip A screenshot will also be precious for me.
BTW I discovered that MAME hangs soon after a floppy disk is replaced by UI means. So I had to reboot if I needed to change a floppy.

On 4/12/2021 at 12:17 PM, mizapf said:

If you don't use the OS routines, you won't have to care about its bytes. You can copy them somewhere and restore them before returning.

 

On 4/12/2021 at 2:17 PM, 9640News said:

Definitely a solution with copy/restore.  He will need to realize that any keyboard, video, DSR, or other XOP calls will use that memory.  I’m also not sure if some of that memory is used during a test for task switching needs.  He will likely need to run disabling interrupts except when he makes an XOP call.

Thank you very much.  It works!  I found out that we can use range >F020-F07F if we don't use XOP.  My program needs vsync interrupts and they can use range >F080-F0BF.

 

[Geneve 9640 benchmarks]

On 4/3/2021 at 9:11 PM, mizapf said:

One of my first projects with the Geneve was to write a Fractal (Mandelbrot) set generator for Graphics mode 6. I put as much time-critical stuff as possible into the on-chip memory, in particular a fixed point additions and multiplication. The program should be around here somewhere.

I have found out that MDOS provides 32 bytes of on-chip RAM for an application program registers but MDOS itself uses all other on-chip RAM for its services by default.  You have written that you could put some of your code there...  Would you like to help me make a similar trick?  I need at least 96 additional bytes there.

[Geneve 9640 benchmarks]

3 hours ago, mizapf said:

Amiga user ... nah, just for gaming. My father wanted it for doing some office work, even bought an XT emulator card, the slowest piece of hardware that sentient beings can conceive. Then came the PC era, my Geneve stayed with me, the Amiga lost ground the more PC games showed up.

I was an Amiga user only in the 1989-1990.  I also used it mainly for games, but also edited and printed my student papers a bit.   I remember my German friend bought a cheap 80286 card for his Amiga in 1990, he just placed it instead of the 68000 and got the IBM PC AT @7 MHz!

We have nice Amiga emulators now, so I made Xlife-8 using FS-UAE.

[Hello World for the Geneve 9640]

I have been able to make Hello World myself.

Quote

       DEF  START
START  EQU  $
       LI   R0,>27
       LI   R1,STRING
       CLR  R2
       XOP  @SIX,0
       BLWP @0

SIX    DATA 6
STRING TEXT 'Hello World'
       BYTE >D,>A,0
       END

It works.  However I had to use two stage process.  I got OBJ-file using the XAS99 cross-compiler.  Then I used LINK under MDOS to get an executable file.  Is it possible to get an executable file with XAS99 directly?  XAS99 can produce binary files but I still miss how to put a binary file to a disk image using XDM99.

[Geneve 9640 benchmarks]

48 minutes ago, mizapf said:

That's wrong.

You are right.  I am not an expert for this system.  Sorry, I was just jumping to conclusions.  Indeed, I was wrong.  In my defense, I can only give two reasons:

1) the TMS9995 architecture is very unusual - I can't imagine that its fast memory is split in two;

2) this TMS9995 memory map (figure2, page 2) shows FFFA-FFFB in the same shading as fast RAM.

So some stereotypes just misled me.  Thank you very much for your correction.  I really thought that there was something wrong on this page.  Anyway, it was just MHO - I always outlined this.

Thank you very much also for your help with the hardware and advice.  I hope to get some more your help in the future.  BTW I have also interest in a topic somehow relating to fractals.  However I prefer more digital "fractals" - cellular automata. I have a multiplatform project Xlife-8 - I began to think about porting it to the TI99/4A but Xlife-8 requires at least 40 KB of RAM...  And you can notice I am (like you) an Amiga user too.  
 

 

 

[Geneve 9640 benchmarks]

30 minutes ago, mizapf said:

What exactly do you believe to be wrong on Ninerpedia?

You know IMHO the next text 

Quote

The CPU, the TMS 9995, contains an own set of memory locations at addresses >F000 to >F0FB and the remaining 4 bytes at the end of the address space, that is, >FFFC to >FFFF (which are the NMI (None Maskable Interrupt) branch vector)

would be corrected on this page.

IMHO all memory locations >F000-F0FF is the TMS9995 fast internal RAM.  The NMI vector is at >FFFC-FFFF and it is in external RAM.

[Geneve 9640 benchmarks]

12 hours ago, mizapf said:

Now here are the test runs on my machine (PIEA, PIEAF0, PIEAF2). The blue text has been added via GIMP.

Thank you very much!  Your results show that MAME has a very good accuracy for the worst case (F200), MAME is only about 2% faster than your hardware.  However cases with faster memory are a bit less accurate: 8300 - 4% faster, F000 - 5% faster.  Anyway it is a very good result the emulation of so rare and unique hardware.

[Geneve 9640 benchmarks]

16 hours ago, mizapf said:

May I point you at page 55 (PDF page 59) of the linked TMS9995 document that says "Crystal frequency MIN=8 NOM=12 MAX=12.1 UNIT=MHz"? You can surely find more information on that if you just browse that document.

 

The input frequency is 12 MHz on the Geneve; there is no need to discuss this, a simple look at the quarz crystal will tell you. The cycle speed is 333ns, as a result of dividing the 12 MHz by 4. I never said that the internal memory works at 12 MHz. I just wanted to explain above why I believe the TMS9995 has a built-in divider instead is just requiring the 3 MHz rate directly.

 

I am afraid the relevant people of Myarc who designed the Geneve are not available for asking.

 

I don't know the cycle times of the DRAM. The SRAM is usually much faster than DRAM; just consider that today's CPU caches are all SRAM. The SRAM in the Geneve is accessed at 0 wait states; I cannot say whether a 4 MHz DRAM can be driven at 0 wait states. This is the relevant question - do we need wait states or not? If yes, the SRAM is faster.

This page is about input frequency but all instruction timings are based on CLKOUT frequency.

I can't agree that DRAM is just slower than SRAM.  It depends on their types.  SRAM is easier to connect and use but it is usually more costly.  So a small amount of SRAM in a system can be cheaper than the same amount of DRAM.  The classical example for this is the TI99/4A killer, the VIC-20 which uses SRAM, not DRAM.

[Hello World for the Geneve 9640]

19 hours ago, InsaneMultitasker said:

What sort of program are you looking to write?  I may have a few simpler program sources  that I could post this weekend, depending on what type of programming examples would be of benefit to you.

I am seeking just a simple example like a program which starts, prints something and ends.

[PAL or NTSC?]

On 4/9/2021 at 11:22 AM, apersson850 said:

No, it's not a joke. As indicated in other responses, the CPU in the TI 99/4A is running from one frequency. It's the same in all consoles. The VDP is running from a different frequency, and that's different for PAL and VDP. Thus you can compare the two, by running a certain number of loops (per CPU frequency) and count the number of interrupts that occurs (per VDP frequency) during these loops. A PAL console will run through 5/6 as many interupts as a NTSC console will.

Let me explain my thoughts about this idea.  I have written code which implemented a simple stopwatch.  I just counted number of interrupts and then divided this number by 60.  It works fine for an NTSC system but for a PAL system we need a different divider, we need 50 instead of 60.  So I sought an easy way to distinguish a PAL system from an NTSC.  I also uses more complex code which uses the TI99/4A timer and is PAL/NTSC independent.  So when I got an idea to make even more complex code to detect PAL or NTSC it sounds for me like a joke.

[Hello World for the Geneve 9640]

Are there any simple application program sources for the Geneve?  I have a plan to write an assembly program for MDOS but I don't know how to do this.  The sources of Hello World or similar programs can help much.  Any other materials which can help for my task can be also very useful.

[Geneve 9640 benchmarks]

17 hours ago, mizapf said:

In case you have not found it yet ... https://www.ninerpedia.org/wiki/Geneve_wait_state_generation

 

(my own graphics; look at the upper left part)

 

The point is: The quarz crystal is 12 MHz, no doubt. The specifications for the 9995 say that you have to connect a clock with 10.7-12 MHz. Hence, this is expressed in this way in MAME and elsewhere. I believe that the 12 MHz do have an effect internally because the machine cycles have much more activity in the 9995 than in the 9900, in particular with the pipelining. That is, the microprograms may actually require the higher frequency, but externally, the 3 MHz are propagated.

 

See also: https://ftp.whtech.com/datasheets and manuals/Datasheets - TI/TMS9995.pdf

page 55 (as printed on the document; PDF page 59)

Of course I know about the TMS9995 datasheet but I missed the Ninerpedia page.  Thank you.  But this page content rises questions.  The schematic there shows a clock divider which is located just on the entry of CLKIN signal.  As you have noticed, according to the TMS9995 datasheet all instruction timings depend only on CLKOUT.  So the internal fast memory definitely works at 3 MHz.  There is no 12 MHz in any official timing data relating to instruction timings.
However there is also a mystery for me about SRAM.  The BBC Micro, a 1982 computer, use 4 MHz DRAM.  So why doesn't the Geneve, a 1987 computer use 3 MHz DRAM?  I can suggest an answer.  Maybe 640 KB DRAM at 3 MHz was too expensive in 1986 and it was easier and cheaper then to add 32 KB of fast SRAM than 32 KB of fast DRAM?

[Geneve 9640 benchmarks]

21 hours ago, mizapf said:

BTW, I'm away from my real hardware until Friday, so someone else with a real Geneve may want to run the Pi calculator and check out the times. Or - you'll have to wait. 🙂

It is nice to get some results from so interesting hardware.  BTW I have just checked a document GENEVE FAQ 05.19.2001 Compiled By Dan H. Eicher (here) - it claims that the TMS9995 uses 3 Mhz clock, not 12 Mhz!  This explains perfectly my results which shows that the TMS9995 is about 3.3 times faster than the TMS9900 at the same clock frequency which perfectly corresponds datasheets.  But why do we have these 12 Mhz in Wikipedia or MAME?  Myarc ads also claim 12 MHz... Maybe it is a value on a quartz which is divided by 4 to feed the CPU?

[Geneve 9640 benchmarks]

I could make custom variants of pi-spigot which could take advantage of fast RAM of the Geneve 9640.  I got the following results (in seconds) for computations of 1000 pi-digits.

               8300     F000     F200
TI-99/4A       69.1    123.8    123.8 
Geneve 9640    30.7     21.8     56.1

The first column shows timings for the TI-99/4A version which puts all code and data in scratchpad RAM.  The second column shows timings for the version which puts all code and data on the page at 0xF000 where the TMS9995 has its fast RAM.  The third column shows timings for the version which puts all code and data on the page at 0xF200 - it is the worst case for both system.  Any version can be used on either the TI-99/4A or Geneve 9640.  I used XB versions but versions for E/A can be used as well, the timings must be the same for XB or E/A.  The F000 and F200 versions use code which is about 5-10% slower than it could be.  It is because of fast RAM at 0xF000 which divides upper RAM block and there is not enough RAM to keep 3000 pi digits there.  The program therefore has to dynamically merge two memory segments and this has overheads.
The results show that for the best cases [email protected] is about 3.3 times faster than the [email protected]  This is rather implausible for me.  The TMS9995 works without wait states when it uses its fast RAM so it must be at least 4 times faster.  Moreover according to datasheets the TMS9995 has better timings for instruction execution than the TMS9995, at least 2 times better.  So the TMS9995 must be at least 8 times faster than the TMS9900 but we got that it is only 3.3 times.  I got all results from MAME.  So I can again think that this emulator doesn't emulate the TMS9995 fast RAM properly.  Helping with real hardware can be very helpful in clarifying this situation.
The results also show that the Geneve SRAM at 0x8300 accelerates program execution about 2 times.  However I don't understand the idea behind it. If the TMS9995 works at 3 MHz with its external RAM then why does it use SRAM?  32 KB DRAM at 3 MHz was quite cheap in 1996...  Any hint?  BTW Is it possible to move SRAM from 0x0000-3FFF to 0xC000-FFFF?  This can slightly speed up the π computation.
All programs are available on the attached disk image.  XB program files have names PIXB, PIXBF0, PIXBF2.  E/A Basic program files have names PIEA, PIEAF0, PIEAF2.  BTW I fixed the timer routine so it is PAL/NTSC independent now.  The ASCII Mandelbrot programs are also on this image. 

bmx.zip

On 4/3/2021 at 9:11 PM, mizapf said:

Here it is. In the MAME startup line you have to add "-colorbus busmouse" to enable the mouse, also "-mouse" to have it captured by MAME (otherwise it may only function as long as your desktop pointer is above the MAME window). You will also have to set the mouse functions in the OSD menu ("Input (this machine)", mouse buttons and analog x and y). I recommend to use a new config directory (-cfg_directory cfgmouse) so that the settings won't be lost when you run the Geneve without mouse next time. MAME has an ugly habit to kill settings of devices that it does not find on the next run.

 

There is a selection German / English after the splash screen; if you see a yellow text cursor, the mouse is working. In the program, use the right mouse button for the menu (sorry, I had an Amiga back in those times).

Thank you very much for your disk image.  I have to confess I have not been able to get this program anywhere else.  I dug this forum and whtech-ftp.  Thanks also for help with a mouse configuration, it is not easy.  Eventually I could run Fractals! I have been impressed by it very much.  Thanks again.  I attached several beautiful screenshots I got with it.

[PAL or NTSC?]

45 minutes ago, vol said:

It sounds like a joke.  We need interrupts to get timings and you ask to use timings to count interrupts.  I seek rather a ROM byte sequence which allows us to distinguish NTSC from PAL.  IMHO there were only several revisions of main ROM...

I've just checked PAL and NTSC ROMs.  Surprisingly they are identical!  So there is no an easy way to find out what system is used.

[PAL or NTSC?]

1 hour ago, mizapf said:

Sure, count the number of interrupts. You can set the interrupt hook at 83C4, use a loop and check how many interrupts have occurred at the end of the loop. NTSC has 60 interrupts per second, PAL has 50.

 

If you don't have the hardware, you can check it e.g. in MAME when you run the drivers ti99_4ae vs. ti99_4a.

It sounds like a joke.  We need interrupts to get timings and you ask to use timings to count interrupts.  I seek rather a ROM byte sequence which allows us to distinguish NTSC from PAL.  IMHO there were only several revisions of main ROM...

[PAL or NTSC?]

Is there an easy way to distinguish a PAL (European) system from NTSC  (American)?  It seems the VDP can't provide this information.

[π spigot benchmark results]

10 hours ago, Tursi said:

.. looks like I might need a copy of XB100 to test this, too, can't seem to locate one.

 

http://ftp.whtech.com/Cartridges/MAME/zip/exbasic1.zip

10 hours ago, Tursi said:

I don't know what you mean by "fixes uppercase"... it doesn't do anything of the sort.

 

But if you are talking about disk access -- that's because it has a different disk controller. MAME emulates hardware disk controllers only. Classic99 has an emulation disk controller that allows it to read Windows files. Since it was emulated anyway, I encoded both uppercase and lowercase versions of the disk devices in the ROM. Again, no translation is taking place, the device controller simply recognizes both.

 

 

Maybe I missed something but when I am under Classic99 XB I type the same letter when Shift button is pressed or released.  I can type a lowercase letter only in Caps Lock mode.  Under MAME a lowercase letter is typed when shift is not pressed and an uppercase when pressed.

[π spigot benchmark results]

On 4/3/2021 at 3:00 AM, Tursi said:

XB 100 existed before the TI99 had a shift key or lowercase in the character set.

 

Not even joking.

 

 I was also confused by Classic99 which fixes uppercase characters when someone works with its Basics (standard or Extended).  MAME does't do so.

[Geneve 9640 benchmarks]

9 minutes ago, mizapf said:

One thing that is still inaccurate are the VDP wait states; I documented them on https://www.ninerpedia.org/wiki/Geneve_video_wait_states

The bad thing is that we recently got the PAL equations, and after putting that into my emulation, things became slightly worse.

 

Second, you always have tolerances for the clock, so you won't get the same numbers for different systems anyway. I suppose we can live with those small deltas.

 

If you are interested in technical details, have a look at Ninerpedia, e.g. https://www.ninerpedia.org/wiki/Geneve_GPL_Interpreter and other articles.

 

Also, as for the speed promises of the manual, I doubt that they ever ran some serious benchmarks.

 

One of my first projects with the Geneve was to write a Fractal (Mandelbrot) set generator for Graphics mode 6. I put as much time-critical stuff as possible into the on-chip memory, in particular a fixed point additions and multiplication. The program should be around here somewhere.

Thank you very much!  So I have to write a custom program for the Geneva which will use Scratchpad RAM at >F000...

[Geneve 9640 benchmarks]

 

3 hours ago, mizapf said:

Ehm, no, the Geneve emulation is also extremely accurate in MAME, take my word for it.

 

I'm not sure what you actually expected. The GPL speed 1 is designed to decelerate the system so much that you get a similar speed as the original TI console, even a bit slower. Otherwise, you would not be able to play the old games.

 

And GPL speed 5 is fastest. As expected.

 

The Geneve is clearly not 4 times faster than the TI. The external speed is 3 MHz as with the TMS9900; the 12 MHz are only inside the CPU.

You know that The MYARC 9640 User's Manual claims

Quote

The Speed can be set at any one of the GPL-speed values listed below:
1 - Normal TI-99/4A in Basic -Slowest
2 - The TI-99/4A in Extended Basic
3 - Approximately 2 times faster than the TI-99/4A.
4 - Approximately 3 times faster than the TI-99/4A.
5 - Approximately 3 1/4 times faster than the TI-99/4A.

So I expected at least 3x speed for GPL speed = 5 but we have only 2x.  Anyway an ML-program which is in scratchpad RAM must be much faster on the [email protected] than on the [email protected]  However my results with my implementation of pi-spigot show that we still have only 2x acceleration.

The computation of 1000 digits of the number π takes about 68s on the TI-99/4A and about 31s on the Geneva...  Both results are taken from MAME.

I attached a new disk image which may be used with standard Basic (E/A cartridge is required too) or with XB.  Load PIEA for the former case and PIXB for the latter.  This disk also contains the MANDEL program. 

3 hours ago, mizapf said:

OK, "very" accurate, not "extremely" accurate ... will have to check a bit further how to improve it. But good enough. The first picture is with GPL speed 5, the second is with GPL speed 1.

Thank you very much for these photos!  I feel like I have touched your hardware.  Would you like to run PIXB or PIEA too?  Results for 100 and 3000 digits would be also very good for me to get.  However it seems that your system is European and this may cause an issue.  I assume that the raster interrupt frequency is 60 Hz but maybe your system uses 50 MHz.  This possible issue can be corrected in line 240.  You can change the divider here to a proper one.  BTW MANDEL timing calculation doesn't depend on PAL/NTSC frequency.  IMHO even if American and European models use the same 3 MHz for the CPU the PAL system should be slightly faster because the NTSC system spends more time handling raster interrupts.  Anyway it interesting to know is there a way how to distinguish PAL system from NTSC?

2 hours ago, InsaneMultitasker said:

I tried to load the program into Advanced BASIC, listing the program crashes the system.  I loaded the file into Extended BASIC, however, lines 164-166 cannot be edited or duplicate - XB reports "LINE TOO LONG".    How was this program entered?

These lines are just too long for the Basic editor but Basic interpreter can handle them.  I used cross-environment to enter this text.  However I have just updated the MANDEL program, I just shortened 2 long lines.  Please use a new disk image below.

1 hour ago, mizapf said:

OK then, I ran MANDEL in Extended Basic/GPL mode on my real Geneve.

 

GPL speed 1: 148.47 sec

GPL speed 2: 108.02 sec

GPL speed 3: 97.26 sec

GPL speed 4: 88.78 sec

GPL speed 5: 78.08 sec

 

Those numbers look much better and match the emulated times quite well, I dare to say.

 

Tim, I just copied the files MANDEL and MANDEL40 from the disk image to my Geneve, no problem with loading. MANDEL40 does not run on my ABASIC4, "name not in table"; it seems to rely on GPL mode, and I guess ABASIC4 runs in native mode.

Thank you very much again!  Your results are almost identical to MAME.  Maybe tiny difference presents because of PAL/NTSC difference.

MANDEL40 requires to load T40 at first.  It allows us to use 40 column screen mode - look here.  

47 minutes ago, InsaneMultitasker said:

Sorry, my post was not clear: I am able to LOAD (via OLD) MANDEL and MANDEL40 within XB and ABASIC however, LISTing MANDEL in ABASIC crashes the interpreter and abruptly exits to the Geneve command line.  XB can LIST and RUN MANDEL but I cannot edit or duplicate line 164 and the other long CALL LOAD statements without decreasing the parameter count.  I was going to edit the program lines to create a copy of the program that would LIST and RUN in advanced basic. Alas, I've run out of time to play for the time being  

 

I'm not sure about ABasic I can't start this Basic from the mdos_gpl_util hard disk image.  It is possible that this Basic may use the same scratchpad RAM locations as MANDEL.  But the updated version of MANDEL must work well under XB editor.

bm.zip

[Geneve 9640 benchmarks]

It seems I have gotten very strange results.  I can't understand them.
I used simple Basic code which plots Mandelbrot fractals in ASCII.  The disk image with this program is attached.  It is easy to use it by OLD DSK#.MANDEL and then RUN.  The size of the plot is 12x12, it may be changed in lines 250 and 260.
Let me present the results:

TI99-4A                     - 145s
Geneve 9640 (GPL speed = 1) - 147s
Geneve 9640 (GPL speed = 2) - 108s
Geneve 9640 (GPL speed = 3) -  97s
Geneve 9640 (GPL speed = 4) -  88s
Geneve 9640 (GPL speed = 5) -  77s

I used XB (option D in the Geneve MDOS menu).  I also used the next command line to start MAME

mess geneve -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 mdos_gpl_util.hd -flop1 mandel.dsk

The hd image from ftp.whtech.com is used.

So how might this be?!  It is rather impossible for me.  Maybe the Geneve works at 3 Mhz in GPL mode?  Is it possible to switch it to 12 Mhz?  However even at the same frequency the TMS9995 must be faster than the TMS9900...  Maybe it is because MAME emulation is very inaccurate for the Geneve?...  So results from real hardware may help a lot.

I attached screenshots with the results.  Please help me figure out why I got so unexpected numbers.  Thank you.

BTW I have noticed that AUTOEXEC on the boot disk doesn't contain the TIMODE invocation...  I tried to add it but this doesn't help.

 

mandel.zip

[π spigot benchmark results]

Thank you very much.

14 hours ago, mizapf said:

I would be highly interested how this could possibly happen. Timing precision is the primary goal for MAME, and scratch PAD access is certainly emulated with 0 WS and 16 bit. This is the highest deviation that I ever heard of.

 

I suppose you are using a current MAME release.

 

Edit: Also, please use the ZIP cartridges primarily, not the RPKs, unless there is no ZIP. That is, you have

and exbasic is guaranteed to work, as I am always using it.

 

Edit2: Please post the pi.dsk file (or send it to me by private message) so that I can test it.

I use MAME 0.229.  My experience with other platforms (Commodore, Atari, ...) shows that MAME sometimes is very poor for software which requires accurate timings.  So I usually use other more tuned emulators.  However for the TI99-4A MAME proves that it is a very accurate emulator for this case.
The problem has been in Extended Basic v100.  It seems it uses a kind of long custom interupt routine which affects timings so dramatically.  All other XB variants shows the same results under MAME - 68.4s which matches other emus results. I tested cartridges editass, exbasic, exbas25, exbaspl,  exbasm, and superxb.  Only cartridge exbasic1 shows a very slow calculation process.
I had problems with some XB variants because I entered a filename in lowercase.  It is interesting that XB v100 fixes keyboard in the uppercase mode.

13 hours ago, Tursi said:

I'd like to run it against hardware as well... but I wasn't able to determine what I needed to pull. The DSK image will cover everyone for testing

I have attached the disk image.  Type OLD DSK#.PIEA for standard Basic with the E/A cartridge, or OLD DSK#.PIXB for Extended Basic.  It is still interesting to get results from the real iron.  I need timings from 100, 1000, and 3000 digit runs.  Thank you in advance.

pi.zip