Enterprise Forever
:UK => Programming => Topic started by: Herbert123 on 2023.February.03. 01:36:10
-
The other day I was watching
https://www.youtube.com/watch?v=H05hM_Guoqk
In the video the presenter tests the following Basic program on various 8-bit machines to compare the TI-99/4A performance - the program is meant to
(https://i.ibb.co/VgBDyj2/graph.png)
The presenter explains that the TI/99's video ram is used to save the basic program in, and therefore the video processing slows down the cpu running the program. Interestingly enough the ZX Spectrum performs very poorly here.
The Amstrad performs best (I used to own a CPC 664 back in the day).
They did not test the Enterprise, and while I still haven't been able to fix and test my Enterprise 64 for a real test with a physical machine, I typed the listing in ep32, and ran it.
(https://i.ibb.co/Jp371Kc/program.png)
To my surprise it took quite a while to complete: a whopping 86 seconds!
Can anyone here with a real Enterprise double-check if it indeed takes that long to complete?
If so, what would a technical reason be? Why would the Enterprise take more than 3 times longer than an Amstrad machine in this particular test?
PS
I ran the same program in WinApe to check if it runs at the same speed as a real one (and it does: same result as in the video).
-
The 128 model will do the same only lasting a few seconds less... It doesn't share the Video memory, so the Z80 is not restricted.
You can test it yourself with the EP128emu (https://github.com/istvan-v/ep128emu/releases/) emulator. It is more up to date than EP32.
It is not the fastest Basic on the universe.... but on the other side the machine offers a good integration of its outstanding features(video, audio) on the Basic commands, so at the end it is enough fast doing its things.
The main characteristic of IS-BASIC is that it conformed strictly to ANSI BASIC (https://en.wikipedia.org/wiki/Full_BASIC), so it was not based on Microsoft Basic, the de-facto standard on almost all microcomputers of the 80's era. It is probably that its complexity made it slower than the other dialects.
I feel it easier to program than the competitors on your chart that I have managed. I specially like its Basic editor and the variety of good commands for almost any task.
If you want more speed you also can try the Zzzip Basic compiler (http://www.ep128.hu/Ep_Util/Prg/Zzzip_12.rar).
-
@gflorez Thanks for the compiler!
I compiled the benchmark, and now it finishes in a little less than 6 seconds! 86 versus 6 seconds. Not bad!
Thanks again!
-
EXOS2.1 ISDOS
(C/PM 2.2)
IS-BASIC 2.1 MicroSoft BASIC 5.21
4MHz 7.12MHz 4MHz 7.12MHz
86 s 41 s 46 s 22 s
Trefe
-
about 25 sec in Altair Basic 4K (Microsoft)
-
We also have the emulated machines to try, Spectrum and CPC...
-
We also have the emulated machines to try, Spectrum and CPC...
I already tested in WinApe CPC emulator: exactly the same result (26 seconds) as on a real machine.
about 25 sec in Altair Basic 4K (Microsoft)
Wow! Where can I find Altair Basic?
@Trefe thank you for the physical machine test! Interesting to see that even on 7.12Mhz IS-Basic is almost twice as slow as on a 4MHz Amstrad.
ps soon I will have access to a real C64 again. Uncle of mine found his while clearing out the loft. :-)
I am on the outlook for an Amstrad 6128.
-
I have not explained me well: The Enterprise can emulate CPC, Spectrum, Commodore16 and TVC.
-
...Enterprise can emulate CPC, Spectrum, Commodore16 and TVC.
Well, actually stating EP can emulate C16 is a bit daring IMHO. Even if you consider only BASIC.
-
Wow! Where can I find Altair Basic?
4k Basic (http://ep128.hu/Ep_Util/Prg/Altair_Basic_4k.rar)
8k Basic (http://ep128.hu/Ep_Util/Prg/Altair_Basic_8k.rar)
description (about Hungarian) (http://ep128.hu/Ep_Util/Altair_Basic.htm)
-
about 25 sec in Altair Basic 4K (Microsoft)
In the picture, the bottom of the screen is cool, with the information about the function keys.
The upper part of the invert characters look a bit ugly as always, they would be pulled down one pixel. But this is not a problem here. Pity that it was not done this way originally.
---
A képen, a képernyő alján király, hogy ott van az információ a funkcióbillentyűkről.
Az inverz karakterek felső része kicsit csúnya, mint mindig, egy pixellel lejjebb kellene tolni őket. De itt ez nem gond nyilván. Gyárilag kár, hogy nem így csinálták meg.
-
Well, actually stating EP can emulate C16 is a bit daring IMHO. Even if you consider only BASIC.
Ah, understood. I tested the "benchmark" in ep32 with the CPC emulator.
It finishes at 31 seconds. 5 seconds slower than a real or emulated CPC.
Seems to me that the CPC emulation on the EP is not as fast as a real or emulated CPC. Still much faster than either exdos basic or altair basic.
Still wondering why the basic interpreters are relatively slow on an Enterprise. I did some more testing with the compiled version on both the EP and the CPC, and while the EP takes ~1.86 seconds (including disk access), the CPC version finishes about 2.6 times faster (~0.7sec).
With disc accessing included the EP takes ~4.87 seconds, and the cpc ~1.9 seconds. Disc accessing seems slower as well on the EP, but I can't be sure without physical machines.
Obviously different compilers, and can't be directly compared - but still. The CPC hardware architecture might be more efficient? Not sure.
(Good news: I might be getting my hands on a real CPC664 again soonish! :-) )
And I really want to hook up my Enterprise 64 to a screen, but I do not have a scart compatible screen right now. Yes, I unfortunately purchased the Spanish video cable... I still haven't been able to test my EP.
-
The time of ~1.86 seconds mentioned above is the one with the disk accessing EXCLUDED. Not included. I tried to edit the post, but it didn't take.
-
It finishes at 31 seconds. 5 seconds slower than a real or emulated CPC.
Seems to me that the CPC emulation on the EP is not as fast as a real or emulated CPC. Still much faster than either exdos basic or altair basic.
CPC emulation on the EP is only a modified CPC ROM, and some modifcation can cause little slowdown, ex if the CPC ROM is placed into video RAM, and AY emulation routine can cause slowdown also, as i remember it is called in each 300Hz interrutp.
Still wondering why the basic interpreters are relatively slow on an Enterprise. I did some more testing with the compiled version on both the EP and the CPC, and while the EP takes ~1.86 seconds (including disk access), the CPC version finishes about 2.6 times faster (~0.7sec).
This basic testing is not the best measurement of capabilities of a computer, because it tells mainly that how fast the basic itself, IS-Basic handles differently the numbers (if i know well) than other Basics, it uses in BCD format, number handling is slower in IS-Basic, and it is much more complex than others.
With disc accessing included the EP takes ~4.87 seconds, and the cpc ~1.9 seconds. Disc accessing seems slower as well on the EP, but I can't be sure without physical machines.
Obviously different compilers, and can't be directly compared - but still. The CPC hardware architecture might be more efficient? Not sure.
Floppy Disk i/o is much faster on Enterprise than on CPC. Normally most of the things can be solved faster on EP than on CPC, because the CPC uses 16 bit I/O ports, Enterprise uses 8 bit I/O ports, and accessing 8 bit I/O ports needs less cpu time, and there is one thing which needs too much instruction on CPC, accessing the keyboard, and AY, 1st you need to program the 8255 PPI to be able to access them, then you can address the needed AY port, and at the end PPI should be instructed again.
-
Still wondering why the basic interpreters are relatively slow on an Enterprise.
For the answer try this test on various computers:
10 FOR I=1 TO 10 STEP 0.1
20 PRINT I
30 IF I=1.3 THEN STOP
40 NEXT I
-
Herbert123, you should better make your tests on the up to date EP128emu.
-
For the answer try this test on various computers:
10 FOR I=1 TO 10 STEP 0.1
20 PRINT I
30 IF I=1.3 THEN STOP
40 NEXT I
I have tested it with a small modification which accepts all computers:
10 FOR I=1 TO 10 STEP 0.1
20 PRINT I
30 IF I=1.3 THEN GOTO 50
40 NEXT I
50 REM
Amstrad CPC counts until 10
Commodore +4 counts until 10
Commodore 128 counts until 10
Commodore 64 counts until 10
Enterprise counts until 1.3 ok
Videoton TVC counts until 1.3 ok
ZX Spectrum counts until 10
-
I tested Herbert's example on Videoton TVC also, it finished under 47 seconds. :D
-
Amstrad CPC counts until 10
And print crazy values :lol:
[attach=1]
-
And print crazy values :lol:
What makes those values crazy? :?:
-
ENTERPRISE and TVC represent floating-point numbers on a BCD basis, while the more common Microsoft BASIC represents them on a binary basis. Since computer processors work in binary, they can process numbers represented in this way faster.
On the other hand, it is not possible, or hardly possible, to express decimal fractions exactly with binary numbers. That is also why, when I studied programming in high school, it was expressly forbidden to test the equality of two decimal fractions in conditional instructions.
In terms of accuracy, ENTERPRISE and TVC spoil us, but the calculation is slower.
Bruce Tanner also wrote about this in one of his posts during the creation of TVC BASIC.
I'm sorry, my knowledge of the English language is weak, I hope it can be understood with google translator.
Trefe
.....
Az ENTERPRISE és a TVC BCD alapon ábrázolják a lebegőpontos számokat, míg az elterjedtebb Microsoft BASIC pedig binárisan. Mivel a számítógépek processzorai binárisan működnek, ezért az így ábrázolt számokat gyorsabban fel tudják dolgozni.
Viszont bináris számokkal pontosan kifejezni a tizedes törteket nem, vagy alig lehet. Ezért is volt annak idején, mikor programozást tanultam a középiskolában, hogy kifejezetten tiltották két tizedes törtszám egyenlőségének vizsgálatát a feltételes utasításokban.
Pontosság szempontjából az ENTERPRISE és a TVC elkényeztet minket, viszont lassabb a számolás.
Erről írt is valamelyik posztjában Bruce Tanner a TVC BASIC készítésénél.
Sanálom, az angol nyelv tudásom gyenge, remélem google translatorral is érthető.
Trefe
-
@Trefe You posted while I was writing this ;-)
Ah, floating-point imprecision causes rounding errors. Am I correct in stating that the Enterprise's basic is using a limited-precision decimal then? Which slows down calculations?
-
It is more the contrary... the EP uses correct precision on BCD, while Microsoft uses an approximation.
The more accurate calculation makes the EP slower.
-
The more accurate calculation makes the EP slower.
But more usable for math calculations! EP have a 10 BCD digit. At my school time available calculators only have a 8 digit.
-
But more usable for math calculations! EP have a 10 BCD digit. At my school time available calculators only have a 8 digit.
...which also affects (slows down) the compiled versions...
Would be nice if Enterprise basic had a way to limit that precision for improved performance.
-
There you go. :D
[attach=1]
-
...which also affects (slows down) the compiled versions...
Compiled version does not slow down (if you mean ZZZIP compiler) it works only with integers and if i remember well from -32768 to 32767.
-
IS-BASIC also "cheats" if both numbers in an operation are 16 bit integers. FOR I=1 TO 1000 STEP 0.1 is slower than FOR I=1 TO 10000 STEP 1. But the overhead of checking for everything being 16 bit integers, converting integers to floating point when they are not, and deaing with 16 bit result overflow, means it is still not as fast as you would like :oops: (and I can't remember if TVC has this!)
-
But more usable for math calculations! EP have a 10 BCD digit. At my school time available calculators only have a 8 digit.
In addition, EP uses 12 digits for internal calculations. It only gives us a value rounded to 10 digits. (see EXOS ROM 0/1 disassembly, RST10 routines and table of internal constants.)
Trefe
-
IS-BASIC also "cheats" if both numbers in an operation are 16 bit integers. FOR I=1 TO 1000 STEP 0.1 is slower than FOR I=1 TO 10000 STEP 1. But the overhead of checking for everything being 16 bit integers, converting integers to floating point when they are not, and deaing with 16 bit result overflow, means it is still not as fast as you would like :oops: (and I can't remember if TVC has this!)
Regarding TVC, Zozo's test was running much faster on TVC until the screen should not be scrolled, did you perform optimalization in TVC Basic in calculation, or the reason is simpler OS, and can reach routines faster on TVC?
-
On Enterprise PRINT works much faster if #102 used directly.
-
Regarding TVC, Zozo's test was running much faster on TVC until the screen should not be scrolled, did you perform optimalization in TVC Basic in calculation, or the reason is simpler OS, and can reach routines faster on TVC?
The core of TVC BASIC is simpler and faster and was a re-write from nothing. The second time you write some code, you write it better :mrgreen:. But it uses the same floating point routines because re-writing those is difficult and takes a long time :lol:.
PRINT is slower on the EP because it goes through the editor: device and then the video: device. Zozo's PRINT #102 bypasses the editor: and goes directly to video:. Everything on TVC is simpler - there is just less code to execute!
-
PRINT is slower on the EP because it goes through the editor: device and then the video: device. Zozo's PRINT #102 bypasses the editor: and goes directly to video:. Everything on TVC is simpler - there is just less code to execute!
I thought similar also, i thought that EP's channel handling slows down the print, but thank you very much for the clarification. :)
What is interesting, TVC has to print the characters on graphics screen, and EP to char screen, and TVC becomes slower only when scroll is coming, but EP's editor is great, i did not see soooo good editor on any other machine :)
-
but EP's editor is great, i did not see soooo good editor on any other machine :)
I was actually quite surprised when I first acquainted myself with the Enterprise CLI a few weeks ago: quite amazing for the time that it was possible to scroll upward and display previous content. I am used to it in modern CLIs, and it was a bit mindblowing to experience this same behaviour on a 8bit machine hearkening from the 80s!
The hardware video splitting was also very surprising.
It's shame the machine was delayed so much that when it finally became available on the market in 1985 16bit machines like the Atari ST and Amiga 1000 were introduced only a few months later - and overshadowed with hardware and software far surpassing the Enterprise.
If only the EP had been introduced early 1984: things would perhaps have turned out quite differently.
That said, even on the Amiga 1000 I cannot scroll content from the CLI back into view like the Enterprise... ;-) (I still own my Amiga 1000! )