Suggestion: Filter/Reduce Bus-Log

[vc64web]

Suggestion: Filter/Reduce Bus-Log

[mithrendal]

yeah I know you would love it.

Curious as I am, I wanted to see, how you are preventing the messages to flow and was able to find live_debug_output but I did not find the place where it is actually used. Well... Not that important, just curiousity :-)

here

https://github.com/dirkwhoffmann/virtualc64web/blob/71f6baf3ea77c4131f0c21d3cb9b5f6755d19fc6/shell.html#L287

also I repaired the centering of the handcrafted virtual keyboard.. It had worked only in firefox..
the reason .. I used the brand new css flexbox style flex-basis: content which is still unknown in chrome and safari 🙄... I just today saw hints in the new safari developer preview that they will support "content" in future... I solved it to work around with two other css styles for max compatibility

the keyboard must be improved though ... I mean look at dirks native vc64 virtual keyboard ... so lovely

[mithrendal]

oh yes... in fact the javascript is already connected to the cores message queue

see here

function message_handler(cores_msg)
{
    var msg = UTF8ToString(cores_msg);
    if(msg == "MSG_READY_TO_RUN")
    {
        //start it async
        setTimeout(function() { try{wasm_run();}catch(e){}},10);
    }
    else if(msg == "MSG_ROM_MISSING")
    {        
        //try to load roms from local storage
        setTimeout(function() {
            FromBase64 = function (str) {
                return atob(str).split('').map(function (c) { return c.charCodeAt(0); });
            }
            var loadStoredItem= function (item_name){
                var stored_item = localStorage.getItem(item_name); 
                if(stored_item != null)
                {
                    var restoredbytearray = Uint8Array.from(FromBase64(stored_item));
                    wasm_loadfile(item_name, restoredbytearray, restoredbytearray.byteLength);
                    return true;
                }
                else
                {
                    return false;
                }
            }
            try{
                var all_fine = true;
                if (!loadStoredItem('basic_rom.bin'))
                    all_fine=false;
                if (!loadStoredItem('kernal_rom.bin'))
                    all_fine=false;
                if (!loadStoredItem('char_rom.bin'))
                    all_fine=false;
                if (!loadStoredItem('vc1541_rom.bin'))
                    all_fine=false;
 
                if(all_fine == false)
                    $('#modal_roms').modal();
       
            } catch(e){}
        
        },0);

    }
} 

so they are already landing in javascript ... but are not handled yet ... we can consume them and do some flashing ... what about the drop zone ? We could flash the drop zones background-color or the border color ...

and we like you said just filter them out the log to reduce it

[mithrendal]

Hi @sy2002
I think I fixed the problem by completely hiding and not feed text into the live debug output by default and by establishing a settings dialog where you can turn it on when there is need for it.

The value settings are stored to localStorage like the dark mode value... so it is persistent

I think your performance issue is gone with this change , do you think we can I close this ?

Or should we still let it open or rename it to "reactive UI on message bus events" ?
You wanted a drive LED to flash somewhere in the UI, do you ?

pushed it to gh-pages...

[sy2002]

@mithrendal Sounds like a perfect solution! Thank you :-) I closed it.

(Curious as I am, I wanted to see, how you are preventing the messages to flow and was able to find live_debug_output but I did not find the place where it is actually used. Well... Not that important, just curiousity :-) )