Post Reply 
ILPer v2.4 update
02-22-2020, 04:00 PM
Post: #1
ILPer v2.4 update
Updated ILPer to v2.4 at https://hp.giesselink.com/hpil.htm. For those who want to know, I added a history file never published before to see the modifications on this software over the last 10 years.
Visit this user's website Find all posts by this user
Quote this message in a reply
02-22-2020, 06:48 PM
Post: #2
RE: ILPer v2.4 update
(02-22-2020 04:00 PM)Christoph Giesselink Wrote:  Updated ILPer to v2.4 at https://hp.giesselink.com/hpil.htm. For those who want to know, I added a history file never published before to see the modifications on this software over the last 10 years.

10 years? Where did the time go?

Thanks again for all your toys. And open sourcing them.
Find all posts by this user
Quote this message in a reply
02-22-2020, 10:53 PM
Post: #3
RE: ILPer v2.4 update
Thanks for the update Christoph!

One of the noted changes is:

"added clear disk drive status after successful reading or writing"

This is an internal "invisible" change, is that correct?

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
02-23-2020, 12:07 PM
Post: #4
RE: ILPer v2.4 update
(02-22-2020 10:53 PM)rprosperi Wrote:  Thanks for the update Christoph!

One of the noted changes is:

"added clear disk drive status after successful reading or writing"

This is an internal "invisible" change, is that correct?

Yep, but not "replaced disk drive status 15" causing an endless loop on the 41 in a special condition and more worse "at disk name setting added drive disk buffer clear" caused reading wrong data also in a special condition on the 41. Both happened "in the wild" and sended as bug report.
Visit this user's website Find all posts by this user
Quote this message in a reply
02-23-2020, 02:56 PM
Post: #5
RE: ILPer v2.4 update
(02-23-2020 12:07 PM)Christoph Giesselink Wrote:  Yep, but not "replaced disk drive status 15" causing an endless loop on the 41 in a special condition and more worse "at disk name setting added drive disk buffer clear" caused reading wrong data also in a special condition on the 41. Both happened "in the wild" and sended as bug report.

Thanks for confirming Christoph. I can understand the the 2nd one too, though that has never happened to me either. And good timing as I have to do some 41 IL stuff later today, so good to know it just got safer.

Thanks again.

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
02-25-2020, 10:27 PM (This post was last modified: 03-04-2020 01:26 AM by compsystems.)
Post: #6
RE: ILPer v2.4 update
Hello C.G. application users.

Related with the applications developed by C.G. (emulators).
It is very useful to add an option to separate the keyboard from the screen , for example in this way the keyboard is holded and the simulation of the screen could be zoomed, or adjust the screen in a specific area of the computer monitor or screen.

Who would like to have this feature in a future release?
I think I will be the last to add in the emulators since they are practically fully developed.

An image of inspiration (CASIO / TI ) SDK
[Image: Fx-9860G_SDK.jpg]

a video



SBASIC -> https://smallbasic-publicwebsite.azurewebsites.net/
Find all posts by this user
Quote this message in a reply
02-25-2020, 10:29 PM
Post: #7
RE: ILPer v2.4 update
(02-25-2020 10:27 PM)compsystems Wrote:  Related to the skins of all emulators, it is very useful to add an option to separate the keyboard from the screen, for example in this way the keyboard is holded and the simulation of the screen could be zoomed, or adjust the screen in a specific area of the computer monitor or screen.

What does this have to do with ILPer??

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
02-25-2020, 10:47 PM
Post: #8
RE: ILPer v2.4 update
(02-25-2020 10:29 PM)rprosperi Wrote:  
(02-25-2020 10:27 PM)compsystems Wrote:  Related to the skins of all emulators, it is very useful to add an option to separate the keyboard from the screen, for example in this way the keyboard is holded and the simulation of the screen could be zoomed, or adjust the screen in a specific area of the computer monitor or screen.

What does this have to do with ILPer??

What does a TI calc have to do here??
Oh well, it's compsystems...

Greetings,
    Massimo

-+×÷ ↔ left is right and right is wrong
Visit this user's website Find all posts by this user
Quote this message in a reply
02-26-2020, 03:28 AM
Post: #9
RE: ILPer v2.4 update
(02-25-2020 10:47 PM)Massimo Gnerucci Wrote:  
(02-25-2020 10:29 PM)rprosperi Wrote:  What does this have to do with ILPer??

What does a TI calc have to do here??
Oh well, it's compsystems...

I think C.G understands me and is a challenge for him. The idea is to have two separate windows, one for the LCD simulator and another window for the keyboard simulator, with options to change the LCD dimension, for which a new command is required within the KML. I can currently create a KML separation LCD screen with keyboard, but I cannot change the size of each part.

In the previous post, place a more detailed image of the CASIO SDK that performs this function.

Per capire

SBASIC -> https://smallbasic-publicwebsite.azurewebsites.net/
Find all posts by this user
Quote this message in a reply
02-26-2020, 04:08 AM
Post: #10
RE: ILPer v2.4 update
(02-26-2020 03:28 AM)compsystems Wrote:  I think C.G understands me and is a challenge for him. The idea is to have two separate windows, one for the LCD simulator and another window for the keyboard simulator, with options to change the LCD dimension, for which a new command is required within the KML. I can currently create a KML separation LCD screen with keyboard, but I cannot change the size of each part.

Why does it help to be able to blow-up the LCD portion of the emulator? The screens in the emulators are reproductions of the original low-resolution screens from the original calculators, so blowing them up would not produce higher resolution graphics with higher accuracy, they would only be larger images of the same low-resolution original screens. How is this an improvement?

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
02-26-2020, 04:33 AM
Post: #11
RE: ILPer v2.4 update
(02-26-2020 04:08 AM)rprosperi Wrote:  Why does it help to be able to blow-up the LCD portion of the emulator? The screens in the emulators are reproductions of the original low-resolution screens from the original calculators, so blowing them up would not produce higher resolution graphics with higher accuracy, they would only be larger images of the same low-resolution original screens. How is this an improvement?

One thing that tends to happen when standard-resolution applications run on high-resolution screens is that the OS will helpfully smooth bit-mapped graphics as it scales them up. Usually, this is a good thing, because it prevents things from looking blocky, but when you're displaying a retro LCD dot-matrix calculator display, that blockiness is actually preferable, because it looks crisper and truer to the original.

If the OS allows applications to control this smoothing behavior, then they could simply turn it off, but if it doesn't, then the app will have to render in full resolution itself. I don't know if this is why compsystems was asking about it, but the unwanted-smoothing issue is one that I have run into on a few platforms myself.
Visit this user's website Find all posts by this user
Quote this message in a reply
02-28-2020, 03:52 AM
Post: #12
RE: ILPer v2.4 update
Another option that I always wanted in emu48 is to show a grid on the LCD screen, in this way the pixel separation seemed to result in a more real simulation of the operation of the LCD screen. It could play with three colors pixel on, pixel off and background color, to show a series of combinations or types of LCD

[Image: real_LCD_on_emulators.png]

SBASIC -> https://smallbasic-publicwebsite.azurewebsites.net/
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)