Post Reply 
Benchmarks 71B versus 48GX
06-17-2020, 08:44 PM
Post: #21
RE: Benchmarks 71B versus 48GX
(06-17-2020 12:36 PM)J-F Garnier Wrote:  If it's really a 1LK7 then it's the same than used in the 28C and it supports the PC=(A) opcode. It may be a way to detect the CPU version by software. I may try.

Ok, I had to do it...

Here is the CPUV function that returns 1 if the CPU executes PC=(A), otherwise 0.

I got 0 on my oldest HP71s, but 1 on my 2842Axxx machine.

Note that both Emu71/Win and Emu71/DOS return 1 since they support the new opcodes.

Forth/assembler needed to enter and assemble the CPUV keyword.
Code:
       LEX 'CPUVER'
       ID #5C
       MSG 0
       POLL 0
       ENTRY CPUV
       CHAR #F
       KEY 'CPUV'
       TOKEN 1
       ENDTXT

FNRTN1 EQU #0F216
FUNCR0 EQU #2F89B

       NIBHEX 00
CPUV
* install hook
       GOSUB IHOOK 
HOOK   
       P= 14
       C=C+1 P   * return 1 if PC=(A) was effective
       GOTO ret

* set FUNCR0 to point to HOOK       
IHOOK  C=RSTK
       AD0EX          * save D0
       D0=(5) =FUNCR0
       DAT0=C A
* now set A[A] to point to FUNCR0
       AD0EX          * and restore D0
* prepare C
       C=0 W
* try PC=(A) 
       NIBHEX 808C     PC=(A)
* return 0 if nop
       C=0 W
       C=0 W
* return to Basic
ret    GOVLNG FNRTN1
       
       END

J-F
Visit this user's website Find all posts by this user
Quote this message in a reply
06-17-2020, 10:23 PM
Post: #22
RE: Benchmarks 71B versus 48GX
I struggled for a moment getting this to work, forgetting to power-off/on to add the new LEX file into the chain. It's been too long... ahem...

I also thought it may be interesting to include the result in the VER$ poll, "CPU: 0" or "CPU: 1"...

Homework for later... into the large, but still growing, list of things to try.

Thanks J-F ! I knew you would have to do this Wink

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
06-18-2020, 06:09 AM
Post: #23
RE: Benchmarks 71B versus 48GX
This is so cool, thanks J-F
(06-17-2020 08:44 PM)J-F Garnier Wrote:  Forth/assembler needed to enter and assemble the CPUV keyword.
Code:
       LEX 'CPUVER'
       ID #5C
       MSG 0
       POLL 0
       ENTRY CPUV
       CHAR #F
       KEY 'CPUV'
       TOKEN 1
       ENDTXT

FNRTN1 EQU #0F216
FUNCR0 EQU #2F89B

       NIBHEX 00
CPUV
* install hook
       GOSUB IHOOK 
HOOK   
       P= 14
       C=C+1 P   * return 1 if PC=(A) was effective
       GOTO ret

* set FUNCR0 to point to HOOK       
IHOOK  C=RSTK
       AD0EX          * save D0
       D0=(5) =FUNCR0
       DAT0=C A
* now set A[A] to point to FUNCR0
       AD0EX          * and restore D0
* prepare C
       C=0 W
* try PC=(A) 
       NIBHEX 808C     PC=(A)
* return 0 if nop
       C=0 W
       C=0 W
* return to Basic
ret    GOVLNG FNRTN1
       
       END

J-F
Find all posts by this user
Quote this message in a reply
06-18-2020, 07:08 AM
Post: #24
RE: Benchmarks 71B versus 48GX
This is so cool, thanks J-F
(06-17-2020 08:44 PM)J-F Garnier Wrote:  Forth/assembler needed to enter and assemble the CPUV keyword.
Code:
       LEX 'CPUVER'
       ID #5C
       MSG 0
       POLL 0
       ENTRY CPUV
       CHAR #F
       KEY 'CPUV'
       TOKEN 1
       ENDTXT

FNRTN1 EQU #0F216
FUNCR0 EQU #2F89B

       NIBHEX 00
CPUV
* install hook
       GOSUB IHOOK 
HOOK   
       P= 14
       C=C+1 P   * return 1 if PC=(A) was effective
       GOTO ret

* set FUNCR0 to point to HOOK       
IHOOK  C=RSTK
       AD0EX          * save D0
       D0=(5) =FUNCR0
       DAT0=C A
* now set A[A] to point to FUNCR0
       AD0EX          * and restore D0
* prepare C
       C=0 W
* try PC=(A) 
       NIBHEX 808C     PC=(A)
* return 0 if nop
       C=0 W
       C=0 W
* return to Basic
ret    GOVLNG FNRTN1
       
       END

J-F
Find all posts by this user
Quote this message in a reply
06-18-2020, 08:00 PM (This post was last modified: 06-19-2020 11:40 AM by Christoph Giesselink.)
Post: #25
RE: Benchmarks 71B versus 48GX
(06-17-2020 08:44 PM)J-F Garnier Wrote:  
(06-17-2020 12:36 PM)J-F Garnier Wrote:  If it's really a 1LK7 then it's the same than used in the 28C and it supports the PC=(A) opcode. It may be a way to detect the CPU version by software. I may try.

Ok, I had to do it...

Here is the CPUV function that returns 1 if the CPU executes PC=(A), otherwise 0.

I got 0 on my oldest HP71s, but 1 on my 2842Axxx machine.

Note that both Emu71/Win and Emu71/DOS return 1 since they support the new opcodes.

Forth/assembler needed to enter and assemble the CPUV keyword.
J-F

When you don't like to fiddle around with the Forth/Assembler module like me, I added the original sources, sources which can be compiled with the HPTOOLs package and a compiled L71 file for importing with the DOSLINK interface.


Attached File(s)
.zip  CPUVER.zip (Size: 1.43 KB / Downloads: 19)
Visit this user's website Find all posts by this user
Quote this message in a reply
06-19-2020, 08:05 AM
Post: #26
RE: Benchmarks 71B versus 48GX
(06-18-2020 08:00 PM)Christoph Giesselink Wrote:  ... I added the original sources, sources which can be compiled with the HPTOOLs package and a compiled DAT file for importing with the DOSLINK interface.

Thanks, Christoph.
It may be better to name the assembled file CPUVER.L71 to reflect its true nature.

To load it in the HP-71B, you will need the PIL-Box and ILPer. Make the DOSLINK "in file" point to the assembled CPUVER file and do "COPY :DOSLINK".

Now, we can build stats on the presence of the 1LK7 in the latest HP-71B?

J-F
Visit this user's website Find all posts by this user
Quote this message in a reply
06-19-2020, 03:40 PM
Post: #27
RE: Benchmarks 71B versus 48GX
(06-17-2020 08:44 PM)J-F Garnier Wrote:  Forth/assembler needed to enter and assemble the CPUV keyword.

Not really. Would you please post the hex dump so that we may create the LEX file just by entering the hex codes using MAKELEX ?

This will take less time than using the Assembler, the compiled LEX file is quite short.

Thanks and have a nice finde.
V.

  
All My Articles & other Materials here:  Valentin Albillo's HP Collection
 
Visit this user's website Find all posts by this user
Quote this message in a reply
06-19-2020, 04:40 PM
Post: #28
RE: Benchmarks 71B versus 48GX
Maybe this should be turned into an article, it's valuable information for the 71B fans.

I can try to do this next time it rains....

I have gone through all my 71's (Thanks a lot J-F!!).

My stats tells me that the earliest I have with 1LK7 CPU is 2630A and according to legend, they started with 2623A. All are 2CCCC or newer

All of them are Plastic Backs, none of my Metal Backs are 1LK7 - the latest I have is 2552A - 1BBBB.

Hope this is helpful.

/KimH

(06-19-2020 08:05 AM)J-F Garnier Wrote:  
(06-18-2020 08:00 PM)Christoph Giesselink Wrote:  ... I added the original sources, sources which can be compiled with the HPTOOLs package and a compiled DAT file for importing with the DOSLINK interface.

Thanks, Christoph.
It may be better to name the assembled file CPUVER.L71 to reflect its true nature.

To load it in the HP-71B, you will need the PIL-Box and ILPer. Make the DOSLINK "in file" point to the assembled CPUVER file and do "COPY :DOSLINK".

Now, we can build stats on the presence of the 1LK7 in the latest HP-71B?

J-F
Find all posts by this user
Quote this message in a reply
06-19-2020, 05:08 PM
Post: #29
RE: Benchmarks 71B versus 48GX
(06-19-2020 03:40 PM)Valentin Albillo Wrote:  Would you please post the hex dump so that we may create the LEX file just by entering the hex codes using MAKELEX ?
This will take less time than using the Assembler, the compiled LEX file is quite short.

It's decades since I used MAKELEX.
I vaguely remember that the LEX is entered as strings of hex characters with a checksum for each entered line.
Can someone can point to the right tool to generate the hex strings and checksum?

In the meantime, here is the assembly listing, if this can help.

Code:
0001 00000             LEX 'CPUVER' 
0001 00000 34055565    NIBASC 'CPUVER  ' 
     00008 54250202
0001 00010 802E        NIBHEX 802E 
0001 00014 00          CON(2) 0 
0001 00016 60          CON(2) #06 
0001 00018 22          CON(2) #22 
0001 0001A 71          CON(2) #17 
0001 0001C 60          CON(2) #06 
0001 0001E 02          CON(2) #20 
0001 00020 A6000       REL(5) FiLeNd 
0002 00025             ID #5C 
0002 00025 C5          CON(2) #5C 
0002 00027 10          CON(2) 0001  
0002 00029 10          CON(2) 0001  
0002 0002B 00000       CON(5) 0 
0002 00030 F           NIBHEX F 
0002 00031 7100        REL(4) 1+TxTbSt 
0003 00035             MSG 0 
0003 00035 0000        CON(4) 0 
0004 00039              POLL 0 
0004 00039 00000       CON(5) 0 
0005 0003E             ENTRY CPUV 
0005 0003E             * * * M A I N   T A B L E * * * 
0005 0003E 000         CON(3) (TxEn01)-(TxTbSt) 
0005 00041 61000       REL(5) CPUV 
0006 00046             CHAR #F 
0006 00046 F           CON(1) #F 
0007 00047             KEY 'CPUV' 
0007 00047             * * * T E X T   T A B L E * * * 
0007 00047           TxTbSt 
0007 00047           TxEn01 
0007 00047 7           CON(1) 07 
0007 00048 34055565    NIBASC 'CPUV' 
0008 00050             TOKEN 1 
0008 00050 10          CON(2) 1 
0009 00052             ENDTXT 
0009 00052 1FF         NIBHEX 1FF 
0010 00055           * 
0011 00055           FNRTN1 EQU #0F216 
0012 00055           FUNCR0 EQU #2F89B 
0013 00055           * 
0014 00055 00          NIBHEX 00 
0015 00057           CPUV 
0016 00057 7900        GOSUB IHOOK 
0017 0005B           HOOK 
0018 0005B 2E          P= 14 
0019 0005D B06         C=C+1 P 
0020 00060 6220        GOTO ret 
0021 00064           * 
0022 00064 07        IHOOK C=RSTK 
0023 00066 132         AD0EX 
0024 00069 1BB98F2     D0=(5) =FUNCR0 
0025 00070 144         DAT0=C A 
0026 00073 132         AD0EX 
0027 00076 AF2         C=0 W 

PAGE 002            
Forth Assembler     

0028 00079 808C        NIBHEX 808C  * PC=(A) 
0029 0007D AF2         C=0 W 
0030 00080 AF2         C=0 W 
0031 00083 8D612F0   ret GOVLNG =FNRTN1 
0032 0008A           * 
0033 0008A             END 

PAGE 003            
Forth Assembler     **** SYMBOL TABLE ****

CPUV    00057 
FNRTN1  0F216 
FUNCR0  2F89B 
FiLeNd  0008A 
HOOK    0005B 
IHOOK   00064 
TxEn01  00047 
TxTbSt  00047 
ret     00083 


 SOURCE : CPUVERS
 OBJECT : CPUVER  
LISTING : :DOSLINK
   DATE : 22:07:01 on 20/06/17
 ERRORS : 000
Visit this user's website Find all posts by this user
Quote this message in a reply
06-19-2020, 06:02 PM
Post: #30
RE: Benchmarks 71B versus 48GX
(06-19-2020 05:08 PM)J-F Garnier Wrote:  Can someone can point to the right tool to generate the hex strings and checksum?

HP-71 BASIC Made Easy, p133.
Find all posts by this user
Quote this message in a reply
06-19-2020, 06:20 PM
Post: #31
RE: Benchmarks 71B versus 48GX
(06-19-2020 06:02 PM)Dave Frederickson Wrote:  
(06-19-2020 05:08 PM)J-F Garnier Wrote:  Can someone can point to the right tool to generate the hex strings and checksum?

HP-71 BASIC Made Easy, p133.

Thanks Dave but I meant the tool to generate the hex strings, not the MAKELEX to enter them.

J-F
Visit this user's website Find all posts by this user
Quote this message in a reply
06-19-2020, 06:42 PM
Post: #32
RE: Benchmarks 71B versus 48GX
Here is the BASIC listing for both DUMPLEX and MAKELEX from the Old HP Forum Archives
Find all posts by this user
Quote this message in a reply
06-19-2020, 06:50 PM
Post: #33
RE: Benchmarks 71B versus 48GX
(06-19-2020 06:20 PM)J-F Garnier Wrote:  
(06-19-2020 06:02 PM)Dave Frederickson Wrote:  HP-71 BASIC Made Easy, p133.

Thanks Dave but I meant the tool to generate the hex strings, not the MAKELEX to enter them.

J-F

Sorry, I didn't read it all. DUMPLEX is on SWAP\CHHU01.

Code:
CPUVER    ID#5C   54 bytes


     0123456789ABCDEF ck

000: 3405556554250202 0B
001: 802E008581816002 66
002: B6000C5101000000 45
003: F710000000000000 A7
004: 061000F734055565 11
005: 101FF0079002EB06 58
006: 6220071321BB98F2 E2
007: 144132AF2808CAF2 EC
008: AF28D612F00      28
Find all posts by this user
Quote this message in a reply
06-20-2020, 07:51 AM
Post: #34
RE: Benchmarks 71B versus 48GX
Thanks Dave for the hex dump.

Now, one question remains : what does the 1LF2 do when it executes the 808C PC=(A) opcode?
Is it a nop or something else?

The 808C opcode is part of the 808x group, in the 1LF2 only the 8080 INTON and 808F INTOFF are defined.
So it depends on how the opcode decoding is done in the 1LF2, but I would expect the 808C opcode to be executed as INTOFF.
It may be possible to prove it, but probably not worth the effort.

J-F
Visit this user's website Find all posts by this user
Quote this message in a reply
06-21-2020, 04:45 PM (This post was last modified: 06-23-2020 06:23 PM by Jonathan Busby.)
Post: #35
RE: Benchmarks 71B versus 48GX
(05-04-2014 10:56 PM)Christoph Giesselink Wrote:  
(05-03-2014 01:57 AM)Mark Hardman Wrote:  HP-28C
1LK7 Saturn CPU (1 MHz)

Sorry, this is wrong. The HP-28C use the same LC frequency generator like in the HP-71B, so the CPU strobe frequency is 600-650 KHz. You can peek the 5 nibble =CSPEED content (#4F00Fh) on a HP-28C with an external peek program. The 5 nibble content is the CPU strobe frequency divided by 16. So a content of #09C05h mean: #09C05h -> #39941d * 16 = #639056d -> ~640 KHz.

If the value present at =CSPEED is generated in a similar fashion to how the value for the entry of the same name on the HP48 is generated, then some corrections are in order. First, on the HP48 series, =CSPEED is generated using the =clkspd routine ( which of course attempts to measure the CPU clock speed ) which is not very accurate, even if display refresh and keyboard scanning are turned off. Secondly, the HP48 series calculators' 32768Hz crystal oscillator seems to vary frequently and the LC circuit that's part of the PLL ( and which uses the crystal oscillator as a reference ) that generates the HFO ( High Frequency Oscillator, which on the HP48G/G+/GX is around ~7.34MHz to ~7.86MHz ) is also subject to frequent variation. So, although the nominal clock speed of the HP-28C may be 640kHz, it may possibly be higher or lower by a non-negligible amount probably due to similar variations in frequency that cause the HP48 series calculators' clock speed to vary, although I believe the variation to be small and on the order of ±20kHz ( ie. it's not so variable that the clock speed would be off by ~360kHz Smile I'd imagine that would have been caught early in the design phase as it would have made the chip unstable Smile ).

In summary, I think that the value stored at "=CSPEED" is not the most reliable indicator of the true clock speed, although I may be wrong though if the HP-28C hardware and its equivalent to the HP48 series "=clkspd" routine differ in some certain crucial aspects Smile

Quote:
(05-03-2014 01:57 AM)Mark Hardman Wrote:  HP-48GX
Yorke (00048-80063, 160 pin QFP), 4 MHz

This is also a mistake. Only very early HP48G Series calculators had a strobe frequency of 4 MHz. The frequency was then reduced to a nominal speed of ~3.68 MHz.

Well, this is not quite 100% accurate. On the HP48 series, taking the HP48G/G+/GX as an example, the clock speed is derived from the aforementioned HFO divided by 2. AFAIK, the nominal clock speed is around either ~3.93MHz or ~3.67MHz, but, due to reasons I've already mentioned, can vary to a non-negligible degree. I have several HP48GXs that have ~3.9MHz+ clock speeds, and, it seems to me that the "nominal" clock speed is around a little below ~4MHz for these. Also, these calculators are *not* "very early" models Smile ( I've measured ~3.9MHz+ clock speeds on HP48GXs manufactured in Singapore, China and Indonesia Smile )

Regards,

Jonathan

( NOTE : Edited this post to fix typos : "Hz" -> "kHz")

Aeternitas modo est. Longa non est, paene nil.
Find all posts by this user
Quote this message in a reply
06-21-2020, 09:55 PM
Post: #36
RE: Benchmarks 71B versus 48GX
Please note that I was quoting specifications from Craig Finseth's HPDATAbase. If there are any corrections, please let Craig know.

(05-03-2014 01:57 AM)Mark Hardman Wrote:  
(05-02-2014 09:23 PM)John W Kercheval Wrote:  Does anyone have a raw chip speed comparison between the 71B and the 48GX?

From Craig Finseth's invaluable HPDATAbase:

Ceci n'est pas une signature.
Find all posts by this user
Quote this message in a reply
06-22-2020, 04:48 AM (This post was last modified: 06-22-2020 04:50 AM by RMollov.)
Post: #37
RE: Benchmarks 71B versus 48GX
(06-21-2020 04:45 PM)Jonathan Busby Wrote:  Well, this is not quite 100% accurate. On the HP48 series, taking the HP48G/G+/GX as an example, the clock speed is derived from the aforementioned HFO divided by 2. AFAIK, the nominal clock speed is around either ~3.93MHz or ~3.67MHz, but, due to reasons I've already mentioned, can vary to a non-negligible degree. I have several HP48GXs that have ~3.9MHz+ clock speeds, and, it seems to me that the "nominal" clock speed is around a little below ~4MHz for these. Also, these calculators are *not* "very early" models Smile ( I've measured ~3.9MHz+ clock speeds on HP48GXs manufactured in Singapore, China and Indonesia Smile )

Regards,

Jonathan

I can confirm that, my HP-48GX is from the latest ones, SN ID30700327 and always reports abt 3.933MHz

Cheers,
Find all posts by this user
Quote this message in a reply
06-28-2020, 02:11 AM
Post: #38
RE: Benchmarks 71B versus 48GX
To my knowledge, there was a second instruction added to the 1LK7, namely RSI (Reset Interrupt System) with an opcode of 80810.

Maybe Jean-François Garnier could enlighten us as to how a late-production HP-71B equipped with the 1LK7 would react to the issuance of that instruction, and how, on the other hand, the 1LF2 in a standard HP-71B would internally decode the corresponding opcode?
Find all posts by this user
Quote this message in a reply
06-28-2020, 07:35 AM
Post: #39
RE: Benchmarks 71B versus 48GX
(06-28-2020 02:11 AM)Giuseppe Donnini Wrote:  To my knowledge, there was a second instruction added to the 1LK7, namely RSI (Reset Interrupt System) with an opcode of 80810.

Maybe Jean-François Garnier could enlighten us as to how a late-production HP-71B equipped with the 1LK7 would react to the issuance of that instruction, and how, on the other hand, the 1LF2 in a standard HP-71B would internally decode the corresponding opcode?

It's has always been a mystery for me why the RSI is opcode 80810 and not just 8081. Maybe this additional fetched nibble gave more time for the RSI execution? I would be glad to get the opinion of people more expert than me in the Saturn chipsets.

Due to this trailing 0, an attempt to execute RSI on a 1LF2 will probably put the CPU out of sync with the next opcodes.

As for the effect of RSI on a HP-71 with 1LK7, I don't know. Actually I'm not sure of the exact effect of RSI on the 28C.

The SASM doc says:
"This instruction causes CPU to consider any input line (ie
input register bits) presently high as a new interrupt. If
the CPU is presently in the interrupt routine it will wait
for an RTI before vectoring, otherwise the CPU will vector
immediately following the RSI instruction. For a complete
discussion on the interrupt system see the CPU Hardware
Specification (A-1LK7-9005-1). This instruction is not
available on the 1LF2 version of the Saturn CPU."


This description is not fully clear for me, and unfortunately, I don't have access to the 1LK7 CPU Hardware Specification.

J-F
Visit this user's website Find all posts by this user
Quote this message in a reply
07-29-2020, 08:40 PM (This post was last modified: 07-29-2020 10:26 PM by Jonathan Busby.)
Post: #40
RE: Benchmarks 71B versus 48GX
(06-28-2020 07:35 AM)J-F Garnier Wrote:  
(06-28-2020 02:11 AM)Giuseppe Donnini Wrote:  To my knowledge, there was a second instruction added to the 1LK7, namely RSI (Reset Interrupt System) with an opcode of 80810.

Maybe Jean-François Garnier could enlighten us as to how a late-production HP-71B equipped with the 1LK7 would react to the issuance of that instruction, and how, on the other hand, the 1LF2 in a standard HP-71B would internally decode the corresponding opcode?

It's has always been a mystery for me why the RSI is opcode 80810 and not just 8081. Maybe this additional fetched nibble gave more time for the RSI execution? I would be glad to get the opinion of people more expert than me in the Saturn chipsets.

Due to this trailing 0, an attempt to execute RSI on a 1LF2 will probably put the CPU out of sync with the next opcodes.

As for the effect of RSI on a HP-71 with 1LK7, I don't know. Actually I'm not sure of the exact effect of RSI on the 28C.

The SASM doc says:
"This instruction causes CPU to consider any input line (ie
input register bits) presently high as a new interrupt. If
the CPU is presently in the interrupt routine it will wait
for an RTI before vectoring, otherwise the CPU will vector
immediately following the RSI instruction. For a complete
discussion on the interrupt system see the CPU Hardware
Specification (A-1LK7-9005-1). This instruction is not
available on the 1LF2 version of the Saturn CPU."


This description is not fully clear for me, and unfortunately, I don't have access to the 1LK7 CPU Hardware Specification.

J-F

Well, it seems you have found one of the many Saturn "opcode holes" Smile I don't know why the RSI instruction was encoded as 0x80810 -- perhaps HP was planning on adding more opcodes in future Saturn chips but they never got around to it?

Anyway, I don't know about the HP-71B 1LF2 or 1LK7 CPUs, but on the Yorke Saturn it seems that invalid opcodes are just ignored. For example, the following code contains the invalid opcode 0x80811 . I̵f̵ ̵I̵ ̵a̵p̵p̵e̵n̵d̵ ̵a̵ ̵0̵x̵0̵4̵ ̵t̵o̵ ̵t̵h̵e̵ ̵o̵p̵c̵o̵d̵e̵ ̵t̵h̵e̵n̵ ̵t̵h̵e̵ ̵R̵4̵=̵A̵ ̵i̵n̵s̵t̵r̵u̵c̵t̵i̵o̵n̵ ̵i̵s̵ ̵e̵x̵e̵c̵u̵t̵e̵d̵ -- EDIT : Actually, I made an oopsie Tongue -- the above invalid opcode with just 0x04 appended is actually SETHEX. If I append 0x104 then it's R4=A , as demonstrated in the following code :

Code:
ASSEMBLE
    NIBASC    /HPHP48-R/
RPL
CODE
    GOSBVL    =SAVPTR
    A=0    W
    R4=A
    LAHEX    0123456789ABCDEF
    NIBHEX    80811104
    A=R4
    P=    15
    GOVLNG    =PUSHhxsLoop
ENDCODE

I've attached an HP48G-R compatible compiled binary of the above code to this message.

( NOTE : The on-calc checksum is # F393h )

Regards,

Jonathan


Attached File(s)
.zip  opcodetest1.zip (Size: 212 bytes / Downloads: 1)

Aeternitas modo est. Longa non est, paene nil.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: