Js99'er

[+Vorticon]

4 hours ago, Asmusr said:

It appears to be cycling around in the TIPI DSR, but I don't know what it's doing there. The only thing that came out of my investigation is that I found a bug, so now it's at least possible to play your game in JS99er from ordinary disk with the fast TIPI mouse emulation, but if you select the full TIPI emulation it gets stuck no matter if you load from TIPI or normal disk. This indicates it has something to do with the mouse emulation.

Oh well... Thanks for looking into it.

[Asmusr]

5 hours ago, dhe said:

@Asmusr I would like for that to happen with-in js99er - so I would have persistent storage moving between machines.

AFAIK, Git repositories are always cloned to a local folder using a native Git client. Js99er cannot access the Git client or the local repository. Google drive, on the other hand, has a REST API for accessing individual files in the cloud.

[+dhe]

31 minutes ago, Asmusr said:

AFAIK, Git repositories are always cloned to a local folder using a native Git client. Js99er cannot access the Git client or the local repository. Google drive, on the other hand, has a REST API for accessing individual files in the cloud.

I agree, so what would be the path forward if someone wanted to have the dskx stored "in the cloud" and available as seemlessly as possible in JS99er on multiple different machines?

[Asmusr]

14 hours ago, dhe said:

I agree, so what would be the path forward if someone wanted to have the dskx stored "in the cloud" and available as seemlessly as possible in JS99er on multiple different machines?

Well as long as the software is not locked to load from DSK1 you can use the Google drives. Otherwise you need a few extra step to load the disk image or TI files from whatever cloud storage solution you use into JS99er. For instance, if you have a folder of TI files on OneDrive, you can load them all onto a disk in one go using the Load Disk button.

[+retroclouds]

I created a 2880 sectors disk that I cannot seem to use in js99er. When loading the disk the browser seems to freeze and cannot recover.

FWIW, the disk does work properly in classic99

Here's the disk image:

SOURCES.dsk

[Asmusr]

23 hours ago, retroclouds said:

I created a 2880 sectors disk that I cannot seem to use in js99er. When loading the disk the browser seems to freeze and cannot recover.

FWIW, the disk does work properly in classic99

Fixed. I was multiplying the start sector by 2 because the disk have more than 1600 sectors, but apparently that's not right. I think I got it from here under Allocation Bit Map.

[+retroclouds]

2 hours ago, Asmusr said:

Fixed. I was multiplying the start sector by 2 because the disk have more than 1600 sectors, but apparently that's not right. I think I got it from here under Allocation Bit Map.

Works great! Thanks for the quick fix 🙂

[Asmusr]

Does anyone have 2880 sectors disks for real?

[RickyDean]

That would be a 1.44 disk formatted by a Geneve on a HFDC wouldn't it? If so then some do. I don't have access at the moment, but do have some formatted to that capacity. FYI

[+InsaneMultitasker]

2880 sectors is equivalent to 720K.  This capacity became more common in the "later" 80s/90s, with the introduction of the 80-track EPROM for the Myarc Floppy controller and present capabilities of the Myarc hard/floppy controller, and full support by a few disk managers like Disk Utilities (John Birdwell).  The 1.44MB capacity (5760 sectors) would be considered uncommon and was also problematic due to incomplete support in the HFDC DSR and the kludge required to manipulate the clusters , since the cluster chain only reached sector 4095 natively.  I don't know that 720K images are that common even now.  (I use 720k for a lot of my work but if I distribute files, I tend to use 360K)

[+mizapf]

720K is useful for 3.5" floppies, since most (almost all) 3.5" drives are 80-track drives. Yes, and the 1.44M format implies HD disks (and a HFDC upgrade). I use some 3.5" disks with 720K capacity on my Geneve.

 

19 hours ago, Asmusr said:

I think I got it from here under Allocation Bit Map.

Do we have an error on that page that should be fixed?

[+arcadeshopper]

just tried dungeons of asgard on js99er and it was boggy slow.. my computer is plenty fast i9 tons of ram

 

oh it seems to be my brave browser.. which is supposed to be chrome.. but in regular chrome its fine /shrug

 

Greg

[+Schmitzi]

On 11/10/2023 at 11:47 PM, Asmusr said:

Does anyone have 2880 sectors disks for real?

 

I have the 80track-modded Myarc DDCC-1 controller, but I never used it with 720KB. Same for the HFDC.

The maximum that I use (IRL and Emu) is 360KB, but my preferred format is 180KB / 40Tracks (best compatibility with other hardware and users)

 

 

 

 

[Asmusr]

I'm experiencing performance issues with the F18A emulation now. For instance, the Alex Kidd demo that The Mole just posted runs at less than 50 FPS in Chrome/Edge. I'm pretty sure I haven't made any changes to my code that could explain this, so unless it's a result of a recent update to the Angular libraries, I think it must be an issue with Chrome. The 5 years old, pre-Angular, version (https://old.js99er.net) runs better in Chrome, but there have been so many changes since then that it doesn't really tell me anything.

 

Firefox is a case of its own, because there I'm getting around 30 FPS (at 3.5% CPU usage!) even for the highly optimized 9918A emulation. https://old.js99er.net is also slow in Firefox, and I'm sure it wasn't slow 5 years ago, so something else is wrong in Firefox.

[TheMole]

10 hours ago, Asmusr said:

I'm experiencing performance issues with the F18A emulation now. For instance, the Alex Kidd demo that The Mole just posted runs at less than 50 FPS in Chrome/Edge. I'm pretty sure I haven't made any changes to my code that could explain this, so unless it's a result of a recent update to the Angular libraries, I think it must be an issue with Chrome. The 5 years old, pre-Angular, version (https://old.js99er.net) runs better in Chrome, but there have been so many changes since then that it doesn't really tell me anything.

 

Firefox is a case of its own, because there I'm getting around 30 FPS (at 3.5% CPU usage!) even for the highly optimized 9918A emulation. https://old.js99er.net is also slow in Firefox, and I'm sure it wasn't slow 5 years ago, so something else is wrong in Firefox.

I've done some benchmarks on the computers I have at hand here (both using the latest version of chrome):

• 2017-era MacBook Air dual-core intel Core-i5 @ 1.6Ghz: ~32fps w/ F18A enabled, sitting idle on the master title screen, 58.8fps (100%) in 9918a mode.
• 2021-era MacBook Pro w/ Apple M1 pro chip: 58.8% on both.

So the newer computer works flawlessly, but the 6-year old one cannot keep up anymore. I can confirm that it used to work flawlessly on the older machine back when I first got it though.

 

*edit* and old.js99er.net works just fine on the 2017-era device as well. 100%

Edited December 20, 2023 by TheMole

[+retroclouds]

Something is wrong with the 9.7.0 version of js99er.net on google chrome.
The emulator doesn't really starts and sticks at frame 0.
Works fine on Firefox and Edge.
Tested with latest Chrome versions Version 120.0.6099.130 (Official Build) (64-bit)

 

[RickyDean]

33 minutes ago, retroclouds said:

Something is wrong with the 9.7.0 version of js99er.net on google chrome.
The emulator doesn't really starts and sticks at frame 0.
Works fine on Firefox and Edge.
Tested with latest Chrome versions Version 120.0.6099.130 (Official Build) (64-bit)

 

Works good on my Chrome 120.0.6099.111 (Official Build) (64-bit).

[+retroclouds]

Works again. I first tried incognito mode and that one was ok. I then checked all cookies and local storage and removed everything in there, but no luck.

At the end I just cleared the browser cache and that was the solution. 

FWIW I thought it had to do with the websocket connection to my tipi, but I had already reset all there. Using the websocket with my tipi was one of the last things I used in my previous browsing session. But again might be unrelated.

[Asmusr]

13 hours ago, retroclouds said:

Works again. I first tried incognito mode and that one was ok. I then checked all cookies and local storage and removed everything in there, but no luck.

At the end I just cleared the browser cache and that was the solution. 

FWIW I thought it had to do with the websocket connection to my tipi, but I had already reset all there. Using the websocket with my tipi was one of the last things I used in my previous browsing session. But again might be unrelated.

Sorry, I have been playing around with a service worker to enable offline use, but ended up removing it again, because some files get stuck in cache as you see. I think a full reload (Ctr+F5) should cure it.

I have converted the F18A VDP emulation to Web Assembly, which takes us some of the way regarding performance, but some of the GPU intensive demos, e.g. Monkey Island, are still much slower than in the old version of js99er, even though the GPU code is practically the same. I need to do some debugging to find out why.

[Asmusr]

I discovered that the thing that killed performance was that I had set the target for the TypeScript transpiler to ES2022 (in May 2023 when I upgraded Angular). I did it because the Angular framework displays warnings without it, but after downgrading to ES2020, the CPU/GPU code runs just as fast as the old version of js99er did.

 

And overall, since I also changed the F18A VDP emulation to Web Assembly, we now have a faster F18A emulation. The Monkey Island demo uses 10% CPU time on my computer instead of 13% in the old version. 😃

 

So it was a good outcome in the end, but I have no idea why targeting a newer version of JavaScript degraded performance so much. My tests showed that accessing a class instance variable was 4-5 times slower in ES2022 than ES2020, which, of course, has a terrible impact on a CPU emulator. Lots of apps could unknowingly suffer from the this.

 

After the change, the performance in Firefox is little better overall, but it's still running at about half the frame rate for no apparent reason. I would like to find a solution, but currently I don't consider Firefox a supported browser.

 

@InsaneMultitasker and @retroclouds could you please check performance and report back?

Edited December 24, 2023 by Asmusr
comma

[TheMole]

For what it's worth, my 2017 macbook air runs most things at 100% now, but the Monkey Island demo tops out at 48fps

Either way, massive improvement, and more than I would've hoped for on this aging machine. Thanks!

[Retrospect]

 

Hi @Asmusr ... sorry it's christmas day and a bug report, this is what I get when I go onto JS99er ... is there a new URL for it now?  
The TI doesn't boot , just the cyan screen, no beep.  

[HOME AUTOMATION]

hmm... 

Executing disk DSR power-up routine.
Executing disk DSR FILES routine (n = 3)

[+retroclouds]

5 hours ago, Retrospect said:

 

Hi @Asmusr ... sorry it's christmas day and a bug report, this is what I get when I go onto JS99er ... is there a new URL for it now?  
The TI doesn't boot , just the cyan screen, no beep.  

You might want to follow the same approach I did (or perhaps press CTRL-F5 as @Asmusr) proposed.
 

 

Edited December 25, 2023 by retroclouds
CTRL-F5 instead of F5

[+retroclouds]

20 hours ago, Asmusr said:

I discovered that the thing that killed performance was that I had set the target for the TypeScript transpiler to ES2022 (in May 2023 when I upgraded Angular). I did it because the Angular framework displays warnings without it, but after downgrading to ES2020, the CPU/GPU code runs just as fast as the old version of js99er did.

 

And overall, since I also changed the F18A VDP emulation to Web Assembly, we now have a faster F18A emulation. The Monkey Island demo uses 10% CPU time on my computer instead of 13% in the old version. 😃

 

So it was a good outcome in the end, but I have no idea why targeting a newer version of JavaScript degraded performance so much. My tests showed that accessing a class instance variable was 4-5 times slower in ES2022 than ES2020, which, of course, has a terrible impact on a CPU emulator. Lots of apps could unknowingly suffer from the this.

 

After the change, the performance in Firefox is little better overall, but it's still running at about half the frame rate for no apparent reason. I would like to find a solution, but currently I don't consider Firefox a supported browser.

 

@InsaneMultitasker and @retroclouds could you please check performance and report back?

@AsmusrFramerate is great, maxing out. But I guess I'm not a great candidate to test because my 12900K intel PC is overpowered and it takes a bunch of stuff to slow it down.

Having said that, there's a way to do that though (independent of the JS99er version). The bigger the log file gets, the slower it gets in the end. This is then when it starts to behave sluggish.

So there's 2 topics that help getting the log to get very big: 1) The periodic framerate display,  2) The disk I/O messages in the log. This makes it especially noticeable when reading/writing large files, e.g. > 100KB

Executing DSR routine for DSK1, PAB in >0A60.
DSK1.INVADERS: Input, Sequential, Display, Variable, 80
Op-code 2: READ
Returned error code: 0

To fix that I have a local js99er version that has the possibility to turn both messages off.