Calculator language
Calculator language
Hi
Has anyone tried to use the floating point calculator language as the language for their software?
It seems Turing complete, but there's no keyboard read or screen write. Maybe the USR function can be used for this.
Any thoughts?
Has anyone tried to use the floating point calculator language as the language for their software?
It seems Turing complete, but there's no keyboard read or screen write. Maybe the USR function can be used for this.
Any thoughts?
Re: Calculator language
I don't get the question.
I have used i.e. the calculator RST on the ZX Spectrum to perform some calculation, but is that what you want to know??
I have used i.e. the calculator RST on the ZX Spectrum to perform some calculation, but is that what you want to know??
Re: Calculator language
I was wondering if anyone had used the calculator RST as their main language for their software, maybe with small parts in ML.
Looking at Fred Nachbaur's software it seems that Mandelbrot-FFP is mainly coded in the calculator language.
Looking at Fred Nachbaur's software it seems that Mandelbrot-FFP is mainly coded in the calculator language.
Re: Calculator language
My latest game "Calculus Mazximus" is calculating a lot, but since the RST-routine is rather slow I programmed all routines in MC self.
I once altered a Mandelbrot that used ZX Spectrum calculator into as much machinecode and as less possible RST-code.
I was able to double the speed only by replacing RST by code.
I once altered a Mandelbrot that used ZX Spectrum calculator into as much machinecode and as less possible RST-code.
I was able to double the speed only by replacing RST by code.
Re: Calculator language
Cons
- Very slow
- Very limited
- Can run from anywhere in memory, as it is just data
- Even the RST 28h instruction has bit 6 set, so it will run even without M1NOT modification
- Up til 3 times the speed of Basic
- Code is fully relocatable
Last edited by mrtinb on Mon Jun 05, 2017 4:34 pm, edited 1 time in total.
Re: Calculator language
Too slow to be even remotely useful and certainly not three times faster than basic although I cannot comment on Fred Nachbaur's work as I could never get anything of his to run.
Just for fun I once did the following..
Call the calculator routine,load a register then stack it, take its square root then use the calculators own built in stack print routine in an m/code loop so as to print a screenful of numbers just see how much faster than basic it was.
The speed difference between the basic version and this was unmeasurable and this was just a simple few bytes long routine so god knows what would happen with a calculator program of any length!!!
For integer work stick to your own routines for floating point work just use basic as it is immeasurably as fast as working with the calculator directly in my opinion though no doubt others may think differently.
Just for fun I once did the following..
Call the calculator routine,load a register then stack it, take its square root then use the calculators own built in stack print routine in an m/code loop so as to print a screenful of numbers just see how much faster than basic it was.
The speed difference between the basic version and this was unmeasurable and this was just a simple few bytes long routine so god knows what would happen with a calculator program of any length!!!
For integer work stick to your own routines for floating point work just use basic as it is immeasurably as fast as working with the calculator directly in my opinion though no doubt others may think differently.
Re: Calculator language
Well it would always be nice to have a "hello world" example in this language (perhaps screen output can be done with the MEM system variable pointing to the display file)
Re: Calculator language
I haven't gone into it in any depth but seeing as the RST28(H) routine allows the use of Basic tokens it shouldn't be too difficult I would have thought.
EDIT.
The use of USR within the calculator allows a jump out of the calculator to a subroutine referenced by the BC pair,and a RET at the end of this subroutine returns back to the calculator.
A jump to say RST10(H) after converting an appropriately stored number into a CHR$ would seem to be a reasonable way to create an "Hello world" scenario.
I might just have a crack at this!
EDIT.
The use of USR within the calculator allows a jump out of the calculator to a subroutine referenced by the BC pair,and a RET at the end of this subroutine returns back to the calculator.
A jump to say RST10(H) after converting an appropriately stored number into a CHR$ would seem to be a reasonable way to create an "Hello world" scenario.
I might just have a crack at this!
Re: Calculator language
Cracking as well
Code: Select all
1 REM 1112222333334444455
10 REM START
11 POKE 16514,239
12 POKE 16515,47 ; jump
13 POKE 16516,5
20 REM STRING
21 POKE 16517,63
22 POKE 16518,61
23 POKE 16519,36
24 POKE 16520,29
30 REM STRING ADDR,LEN
31 POKE 16521,48 ; stk-data
32 POKE 16522,129
33 POKE 16523,133
34 POKE 16524,64
35 POKE 16525,4
40 REM STK FETCH AND PRINT
41 POKE 16526,48
42 POKE 16527,124
43 POKE 16528,53
44 POKE 16529,192
45 POKE 16530,41 ; usr
50 REM END
51 POKE 16531,52 ; end-calc
52 POKE 16532,201
100 RAND USR 16514
- Attachments
-
- calc.p
- (1.52 KiB) Downloaded 175 times
Re: Calculator language
Why not use
10 PRINT "HELLO WORLD"
which is just much shorter.
10 PRINT "HELLO WORLD"
which is just much shorter.