Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

revamping the ROMs dialog ... #50

Closed
mithrendal opened this issue Aug 14, 2020 · 31 comments
Closed

revamping the ROMs dialog ... #50

mithrendal opened this issue Aug 14, 2020 · 31 comments
Labels
enhancement New feature or request

Comments

@mithrendal
Copy link
Collaborator

now:

grafik

goal:
grafik

@mithrendal mithrendal added the enhancement New feature or request label Aug 14, 2020
@mithrendal
Copy link
Collaborator Author

I will find the cute rom chip images from the picture above in the xcode project right ?

@dirkwhoffmann
Copy link
Collaborator

I will find the cute rom chip images from the picture above in the xcode project right ?

Yes. They are in virtualc64/Resources/Assets.xcassets 😎

@mithrendal
Copy link
Collaborator Author

work in progress ... the rom pictures are already set dynamically ... also is the delete rom trashcan ...

dark mode:
grafik

light mode:
grafik

Ah and the button Install Open Roms is missing do you think we have to ask them in order to fetch the generic roms from their github site ?

In this issue MEGA65/open-roms#33 @gardners said

Would it help if we had some well-known URL with ROMs and
the checksums there, that could be slurped down by VC64 when someone clicks
the "get openroms" button?

Do you think it is ok with them to automatically load them from https://github.com/MEGA65/open-roms/tree/master/bin and store them into the local storage of the browser ?

@dirkwhoffmann
Copy link
Collaborator

Very nice 😎

Do you think it is ok with them to automatically load them...

Yes, I think that's fine. I thinks it's best to implement the prototype just the way you want at the moment. Once this is done, we ask if this is OK for them.

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 15, 2020

quite done ... but before we automatically slurp in the open roms ... I wanted to test them out ...

and the current files give me an error

grafik

any idea ?



 ROMFile *rom = ROMFile::makeWithBuffer(blob, len);

    if (!rom) {
        printf("Failed to read ROM image file %s\n", name);
        return "";
    }

it accepts the open roms charset but not the kernal and not the basic 😢

Another question: how to know whether it is a mega rom or a commodore rom ... is the kernal capable of telling me this ? I need it in order to show the correct rom picture

I pushed the preview to gh-pages ...

@mithrendal
Copy link
Collaborator Author

I can't even run them in vc64Mac ... it seems to me that the current open rom kernal and basic is not even accepted in vc64Mac too ... not even in latest Version 3.4 ... Or am I doing something wrong here ...

the magic header must have been changed ...no ?

@dirkwhoffmann
Copy link
Collaborator

the magic header must have been changed ...no ?

Yes, that's right. The v3.4 core just checks the header signature and is not compatible with the latest Roms. The v4.0 core (dev branch) is smarter and can handle the latest Roms (there are magic bytes and version numbers at fixed memory locations inside the Rom, but they are not at the beginning). But please do not use the v4.0 core yet, because it's far from being ready. Maybe it's better to just update the magic header bytes in vc64web to match the current Roms.

@mithrendal
Copy link
Collaborator Author

Maybe it's better to just update the magic header bytes in vc64web to match the current Roms.

sounds good ... how and where to patch ? can you give me a quick hint ?

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 15, 2020

wait don't do anything I found all pieces ... 🤓

... and I output generate the "magic" header bytes of the latest open roms...

grafik

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 15, 2020

grafik

😎 online ... open roms in a browser

next I do the "install" button to slurp the open roms automatically in ...

grafik

I plan to show the different ROM pictures according to the header bytes which I can read in Javascript too...
*open roms header -> MEGA65 chip picture
*else -> MOS chip picture

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 16, 2020

I patched the core 😷 .

bool
C64::isRunnable()
{
    return
    mem.basicRomIsLoaded() &&
    mem.characterRomIsLoaded() &&
    mem.kernalRomIsLoaded() /*&&
    drive1.mem.romIsLoaded() &&
    drive2.mem.romIsLoaded()*/;  //patch mithrendal to make it work without commodore disk rom
}

as a result vc64web runs with open roms only ...

grafik

it can play the pacman .crt file version 😎✌️

... next task: the open roms install button

@dirkwhoffmann
Copy link
Collaborator

I patched the core 😷 .

Now, we have a VC1541 without a Rom 😬. But if the drive is not accessed, nobody cares 😉.

On my iPad, I experienced the following (yesterday evening):

  • It booted with the original Roms (from the cache), but it did show the Mega64 icons 😮.
  • It told me to drag and drop Roms (which I didn't know how to do on the iPad 🤓).

P.S.: I'll work on a nicer icon when Big Sur comes out, because all icons need to be adjusted to the new icon layout anyway.

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 16, 2020

told me to drag and drop Roms (which I didn't know how to do on the iPad 🤓).

Therefore I added the sentence: „or just touch or click the sockets.“

but it did show the Mega64 icons 😮.

Yes I have to recognize the header and according to the results set the picture. Does the core 3.3 have a method for that? Otherwise I will do in JavaScript which is easy.

Next install open roms button 🤤

@dirkwhoffmann
Copy link
Collaborator

Does the core 3.3 have a method for that?

No, the Rom handling is done in the Swift part 🙄. But the v4.0 core has 🤩.

OK, let's postpone this until the v4.0 core is ready.

@mithrendal
Copy link
Collaborator Author

... the cross site request for the roms may make trouble

we are hosted at
https://dirkwhoffmann.github.io/

and the roms are
https://github.com/MEGA65/open-roms/raw/master/bin/basic_generic.rom

when github.com is different to github.io we may have a cross domain request and that is most likely prevented by the browser police, except github has enabled CORS (Cross-Origin Resource Sharing)

I am testing this now ...

@dirkwhoffmann
Copy link
Collaborator

that is most likely prevented by the browser police

Github.io and GitHub.com are separated? Really? 😮

Let's call this guy for help. No? I mean he already did it once....

Bildschirmfoto 2020-08-16 um 16 20 13

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 16, 2020

I have just deployed the version which loads the local version of the basic.rom fine in order to test it on the wild site

and the police is strict ...
this is what the firefox console outputs ...

Quellübergreifende (Cross-Origin) Anfrage blockiert: 
Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource 
auf https://github.com/MEGA65/open-roms/raw/master/bin/basic_generic.rom. 
(Grund: CORS-Anschlag schlug fehl).

😩

Wait ... why "Anschlag" 🤔 ? I just submitted a read to that ressource ... looks like the browser thinks that could be evil... It gives this further read https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

we could still host the files on our site 🤕

@dirkwhoffmann
Copy link
Collaborator

looks like the browser thinks that could be evil...

So mean 😖

we could still host the files on our site 🤕

Yes, I think that's the best workaround for now. We can update the Roms manually from time to time.

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 16, 2020

Yes, I think that's the best workaround for now. We can update the Roms manually from time to time.

yes, acceptable fallback...

I am just digging deeper in analysing the problem ...

for making CORS work the target webserver has to explicitly accept the request origin ...

our request header

grafik

and the open roms site response header

grafik

if we could just rewrite our origin ... 😁 I think not possible ... or set the access-control-allow-origin header on the target website ...

the host is both times github.com but the origin is different ...

@mithrendal
Copy link
Collaborator Author

I just read that github-pages has CORS enabled by default

Github Pages now has CORS enabled.

The CORS header:

Access-Control-Allow-Origin: *

Is added by default on all responses from Github pages!

that means when openRoms project setup a gh-pages branch and publish their builds there ... then we can fetch the roms from there on a button click from our vc64web app...

@dirkwhoffmann
Copy link
Collaborator

then we can fetch the roms from there on a button click from our vc64web app...

OK, cool, we can ask them if they do this.

Be honest. He helped you, didn't he?

Bildschirmfoto 2020-08-16 um 17 14 04

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 16, 2020

yes I was looking for freedom ... 😂

in the mean time I do host a copy of the open roms at our dirkwhoffmann gh pages in our roms folder...

@mithrendal
Copy link
Collaborator Author

finished 😅

  • it does recognize the latest MEGA ROMS and shows only then its ROM picture otherwise the MOS picture
  • the fetch and install "open roms" button installs the copy from our gh-pages roms folder

grafik

@dirkwhoffmann
Copy link
Collaborator

It works 🥳. Also, my Emoji keyboard is still there 😎.

Bildschirmfoto 2020-08-16 um 18 40 57

@mithrendal
Copy link
Collaborator Author

Github Pages now has CORS enabled.
The CORS header:
Access-Control-Allow-Origin: *
Is added by default on all responses from Github pages!

Before we ask the open roms team about better to publish the roms to gh-pages branch ... we should check whether it is really working what the above stackoverflow posting claims 🤔...

👀lets try chrome this time ... I don't want to risk another "Anschlag" 😌...

I will start vc64web now from localhost and let it fetch the roms from our dirkwhoffmann gh-pages space...

one two three go !!

😵

it is does not load it

let look in the javascript console then

Access to XMLHttpRequest at 'https://github.com/dirkwhoffmann/virtualc64web/raw/gh-pages/roms/basic_generic.rom' 
from origin 'http://localhost:8080' has been blocked by CORS policy: 
The 'Access-Control-Allow-Origin' header has a value 'https://render.githubusercontent.com' 
that is not equal to the supplied origin.

it is not working .... the post was apparently a wrong ...

lets check the headers

request

GET /dirkwhoffmann/virtualc64web/raw/gh-pages/roms/basic_generic.rom HTTP/1.1
Host: github.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36
Accept: */*
Origin: http://localhost:8080
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: http://localhost:8080/
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7

response:

HTTP/1.1 302 Found
date: Sun, 16 Aug 2020 18:52:17 GMT
content-type: text/html; charset=utf-8
server: GitHub.com
status: 302 Found
vary: X-PJAX, Accept-Encoding, Accept, X-Requested-With, Accept-Encoding
access-control-allow-origin: https://render.githubusercontent.com
location: https://raw.githubusercontent.com/dirkwhoffmann/virtualc64web/gh-pages/roms/basic_generic.rom
cache-control: no-cache
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
expect-ct: max-age=2592000, report-uri="https://api.github.com/_private/browser/errors"
content-security-policy: default-src 'none'; base-uri 'self'; block-all-mixed-content; connect-src 'self' uploads.github.com www.githubstatus.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com cdn.optimizely.com logx.optimizely.com/v1/events wss://alive.github.com; font-src github.githubassets.com; form-action 'self' github.com gist.github.com; frame-ancestors 'none'; frame-src render.githubusercontent.com; img-src 'self' data: github.githubassets.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com; manifest-src 'self'; media-src 'none'; script-src github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com; worker-src github.com/socket-worker.js gist.github.com/socket-worker.js
Content-Length: 159
X-GitHub-Request-Id: C968:29F3:6416D80:8FC3F5E:5F3980E0



no way ...
maybe they set it once to access-control-allow-origin: *
now it is access-control-allow-origin: https://render.githubusercontent.com

@mithrendal
Copy link
Collaborator Author

maybe we have to enable CORS in the gh-pages settings... unfortunately I have no access ... only you ... I will make fork and look into the settings of gh-pages...

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 16, 2020

no I found nothing ...

but I found this in https://stackoverflow.com/questions/26416727/cross-origin-resource-sharing-on-github-pages

It seems that GitHub allows it only for HTTPS pages now. Please, update your answer accordingly. – Styx Oct 13 '19 at 9:49

maybe ressource sharing from ghpages works only when consumer is https hosted ... lets test ...

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 16, 2020

I fork vc64web now to mithrendal and deploy to gh pages on mithrendal ...

ok done...

now lets modify vcweb64 on dirkwhoffmann to get roms from mithrendal to have a different origin ...

both are https and gh-pages but different origin so the browser police should be active and hostile 🙈

lets go !

ressource

Request URL: https://mithrendal.github.io/virtualc64web/roms/chargen_openroms.rom
Request Method: GET
Status Code: 200 
Remote Address: 185.199.108.153:443
Referrer Policy: no-referrer-when-downgrade

request

:authority: mithrendal.github.io
:method: GET
:path: /virtualc64web/roms/chargen_openroms.rom
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
origin: https://dirkwhoffmann.github.io
referer: https://dirkwhoffmann.github.io/virtualc64web/
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36

response:

accept-ranges: bytes
access-control-allow-origin: *
age: 160
cache-control: max-age=600
content-length: 4096
content-type: application/octet-stream
date: Sun, 16 Aug 2020 19:51:59 GMT
etag: "5f3986d8-1000"
expires: Sun, 16 Aug 2020 19:54:02 GMT
last-modified: Sun, 16 Aug 2020 19:19:52 GMT
server: GitHub.com
status: 200
vary: Accept-Encoding
via: 1.1 varnish
x-cache: HIT
x-cache-hits: 1
x-fastly-request-id: fe6c86832f009a4e5e4fe199fe850b504ce0f692
x-github-request-id: 1616:47A1:BB59BC:E81BC3:5F398C82
x-proxy-cache: MISS
x-served-by: cache-hhn4072-HHN
x-timer: S1597607520.826902,VS0,VE0

Wow it works ... the proof ...
grafik

gh pages gives us a access-control-allow-origin: * now !!

@dirkwhoffmann
Copy link
Collaborator

maybe we have to enable CORS in the gh-pages settings... unfortunately I have no access ... only you ...

If I understood your posts correctly, I don't have to change anything, do I?

@mithrendal
Copy link
Collaborator Author

mithrendal commented Aug 18, 2020

you understood it right. I only needed access to the settings to analyse whether there is a CORS enable setting or not ... then to get access to the settings I forked the repo ... I looked into it but found no such setting

then I configured the dirkwhofmann/vc64web to access mithrendal/vc64web/roms/... because that is another origin it should activate the CORS prevention policy, and prevent the access except that the target site is explicity stating that it is ok with sharing its contents...

The test revealed that when the app which has been loaded from https://dirkwhoffmann.github.io/virtualc64web/ requested resources from https://mithrendal.github.io/virtualc64web/roms/ ... the gh-pages server answered with header access-control-allow-origin: * which allowed the CORS
between the two origins

in the picture above you see the app is loaded from dirkwhoffmann (look in the addressbar at the top) and that it loads the roms from mithrendal (look into the network analyser at the bottom)

also ... good to know ... when the requesting origin is loaded from a nonsecure (no https) site the gh-pages server does not grant the CORS

in short

we can perfectly slurp in the roms from the MEGA64 open roms site, if they set up a gh-pages branch and publish the prebuilt roms into there

@mithrendal
Copy link
Collaborator Author

mithrendal commented Sep 4, 2020

it works they set it up and we are slurping in the newest roms from their web site from now on !!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants