revamping the ROMs dialog ...

[vc64web]

revamping the ROMs dialog ...

[mithrendal]

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

[dirkwhoffmann]

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]

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

dark mode:

light mode:

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]

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]

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

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]

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]

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]

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]

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

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

[mithrendal]

😎 online ... open roms in a browser

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

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]

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 ...

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

... next task: the open roms install button

[dirkwhoffmann]

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]

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]

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]

... 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]

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....

[mithrendal]

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]

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]

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

and the open roms site response header

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]

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]

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?

[mithrendal]

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]

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

[dirkwhoffmann]

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

[mithrendal]

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]

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]

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]

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 ...

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

[dirkwhoffmann]

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]

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]

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