Emulators that can be connected to

[brickviking]

I thought I'd bust this out to its own thread, so I don't derail the original.

(09-08-2018 12:19 AM)Namir Wrote:  1) Matlab
2) Mathematica
3) Excel

I apologize for my 21st century response!

:-)

Namir

No need to apologise. I can't say the same, however - most of my calculators are physical or emulated HP/Casio/Sharp/Other. Since I came across x49gp a while ago, it's been my go-to calculator for making stuff work, aside from its obvious lack of USB connectivity. Its SD card access is great though.

Actually, that brings up a couple of points I had about emulators.

1. Do any of the "well-known" 48-series (48/49/49+/50) emulators provide a way to connect to them over a simulated conn4x USB/Serial connection? I know that every time I try to use HP's HP-50G 2.16 emulator, it crashes my computer as soon as it touches COM4. Most frustrating, not only that, but the fact I can't install libraries on it either, nor access an SD card for it makes this a curiosity, but hardly a valid working machine.
2. Is there a cycle-accurate emulator for any of the 48-series? I've tried EMU48 and x48, neither one seems to be within cooee of exact speed, though there could be a number of reasons for this. The benchmark I used in each case was the recent Summation test for calculators, I ran it on x48 with +throttle, and got a speed about 30% faster of what real-world results showed on pier4r's list. (36.8 seconds instead of 55 for sum to 1000, and 370 instead of 541 for 10,000). I then tried it with EMU48 and still got a difference, this time in the other direction (63 seconds for 1000).
   

(Post 277)

[Christoph Giesselink]

(09-08-2018 11:58 AM)brickviking Wrote:  2. Is there a cycle-accurate emulator for any of the 48-series? I've tried EMU48 and x48, neither one seems to be within cooee of exact speed, though there could be a number of reasons for this. The benchmark I used in each case was the recent Summation test for calculators, I ran it on x48 with +throttle, and got a speed about 30% faster of what real-world results showed on pier4r's list. (36.8 seconds instead of 55 for sum to 1000, and 370 instead of 541 for 10,000). I then tried it with EMU48 and still got a difference, this time in the other direction (63 seconds for 1000).

First of all, if you would compare the execution time of different calculators of the same model or repeat the benchmark on the same calculator with different humidity or temperature, you may get different results. In the manual self test mode <ON><D> there's a CPU speed test <A> reporting the actual CPU frequency in Hz.

But there isn't any cycle-accurate emulator for the 48-series. The reason, if the execution code for a Saturn CPU is loaded from an external 8-bit device like a static RAM or a 8-bit ROM chip, the same opcode has a different timing executed on an odd or on an even address!

Emu48 use the CPU-cycles described in the SASM document when reading from a ROM chip with 4-bit Saturn bus interface. These given cycles are independent from the opcode loading address. So the speed slow down is by default inaccurate because the cpu speed slow down factor is only estimated. This is acceptable for the main usage: playing games.

It's possible to adjust the speed factor inside the registry:

Code:


[HKEY_CURRENT_USER\Software\Emu48\Emulator]
"SXCycles"=dword:00000052
"GXCycles"=dword:0000007b
"GPCycles"=dword:00000171
"G2Cycles"=dword:000000f6

Each number are the allowed CPU cycles in a 1/16384Hz time frame.

Emu48

• "SXCycles" used by 48SX
• "GXCycles" used by 38G, 39/40G, 48GX, HP49G
  

Emu48+

• "SXCycles" used by 48SX
• "GXCycles" used by 48GX
• "GPCycles" used by 39G+, 49G+
• "G2Cycles" used by 38G, 39/40G, 48GII, HP49G
  

The usage of "G2Cycles" for the 38G, 39/40G, HP49G is a bug inside the Emu48+ source code. I think that will be fixed in v1.60+.