Hallo Besucher, der Thread wurde 8k mal aufgerufen und enthält 35 Antworten

letzter Beitrag von Gurce am

Announcing the Eleven Development Environment for the MEGA65

    Zitat von ubik

    IIRC keyboard registers are outside of vic, so they don‘t need vic-iv enabled...

    I don't think it's how it works. It's I/O mode (called VIC I/O mode, that's true, kinda confusing), like even changes how CIAs are decoded for example CIAs has "echoes" in the memory map in VIC-II mode (thus being compatible with C64 in this regard - though I am not very sure about this one ...). And so on. As you can see MEGA65 memory map, the whole I/O area have three instances for the three I/O modes at "very high addresses though". For the "legacy" I/O area at $D000 (if it's visible) you'll see the one corresponding of your actual I/O mode. If you see iomap.txt in mega65-core repo, in theory, all registers in the $DXXX area marked as GS are only available for MEGA65 I/O mode (also called VIC-IV I/O mode), C65 marked ones are in C65 mode (also called VIC-III I/O mode). At least this is how I understood and Xemu at every places on decoding ANY I/O area access works this way. So if it is not true it would have caused already many-many problems everywhere, I think. Maybe it's called "VIC" I/O mode since the register is in VIC to "key" the mode. But even in C65 it's not clear that "VIC is only VIC", see for example that VIC-III can map ROMs ... Which wouldn't be VIC's task strictly speaking.

    Zitat von ubik

    Ah. That might explain the error! Could it be that BitShifters ROM enables the vic-iv by default?

    It is possible ... Snoopy also had some "binary patches" here for the official ROMs do similar things ... And so on. So if basically this is the problem, it won't work on real MEGA65 either, using "stock" C65 ROM which uses VIC-III (aka "C65") I/O mode by default in C65 mode.


    And one possible trap: I am not sure, but IIRC there is also the "trick" that C65 ROM sets I/O back and forth even in IRQ routine (or just when doing disk I/O? I can't remember ...) thus even if you try to "key" vic-iv I/O mode it may have been reset to VIC-III by the ROM. The same even applies to projects written in assembly, C, whatever, if original IRQ may work in the background. Of course a "patched" ROM using VIC-IV I/O mode always instead of VIC-III would workaround this problem, but it always have its dangers that we forget to set I/O mode and then program does not work with ROMs (including "stock" ones) does not do that (as on C65 of course there was only VIC-II and VIC-III I/O modes).

    Just uploaded version 0.3.2 to https://files.mega65.org?id=8b…1e-45a7-a4de-87bcb0b11696


    Changes:

    - EE: bugfix for an issue where the "alt" key would not be detected on ROM versions not forcing VIC-IV context (thanks LGB and Snoopy)

    - optimizes code generator to emit less spaces and colons

    - removes faulty VIC-IV activation in autoboot (thanks BitShifter)

    - fixes a bug where the label table would get corrupted and/or the compiler would crash (thanks BitShifter)

    - some cleanup in documentation

    Uploaded version 0.4 to https://files.mega65.org/?id=8…1e-45a7-a4de-87bcb0b11696


    Changes / new features:

    • now requires ROM>=920147. Older versions of the 'closed ROM' had a bug which could cause severe data corruption; also, Eleven now uses some of BitShifter's advanced features; thus compatibility with horrible old C= BASIC was dropped in this version.
    • EE: fixes a bug where pressing pgUp would crash the editor under certain circumstances
    • EE: adds find & replace
    • preprocessor: fixes a bug where keywords wouldn't properly be recognized
    • preprocessor: adds support for byte ("&") data type
    • preprocessor speedup (thanks BitShifter)
    • bugfix in % prefix handling (thanks BitShifter)
    • fixes "basedemo.el" (thanks Amok)
    • groundwork laid for further enhancements such as memory resident operation
    • updated README

    That‘s a wonderful idea! The editor is working independently from the precompiler, so there would be no problem from that side.

    Now we just need the assembler module.
    With the MEGA65‘s 40MhZ speed it should even possible to implement the assembler part in BASIC65 (or even better, with ELEVEN itself...)


    I‘d love to do it myself, but then I‘ll never finish my RPG project (which was pushed to the sidelines already because of ELEVEN...)


    So, any volunteers? ;-)

    Hi there!


    As a brand new M65 user (yeah :thumbsup:) I found ELEVEN on the disk and tried it out. Is there still progress on that project?

    I found out that for the command "COLLISION type [, line number]" it is not possible to set a label for the "line number". Or, at least, I didn't find out. Does anybody know how to workaround line numbers in ELEVEN?

    Heya Birko, glad you're enjoying your new MEGA65 and having fun with Eleven also :-)


    I'm a big fan of Eleven too. The version presently shared on the Intro Disk is Ubik's final release version, though since then, I asked him if he was fine for the project to be open-sourced so that others in the community can contribute additions and improvements to it also. He was happy for that, so I've put his project in a github repo, and I make incremental tweaks to it from time to time.


    More info on these topics here (including a link to the github repo):


    https://mega65.atlassian.net/w…209812/Eleven+Walkthrough


    I'm not sure if my modified version will have a fix relating to COLLISION, but you're welcome to have a try of it and see (I'm on holidays presently so can't assess it right now).


    If it doesn't work there either, you're welcome to contribute a fix for it into the repo. I'm guessing it'd require digging into the basic logic inside the "11.parse" file on the disk and assessing how it handles COLLISION.


    If you prefer browsing/studying the parser source from your pc, here's a link to the ascii text outputted from the petcat tool:


    https://github.com/MEGA65/eleven/blob/main/11.parse.bas


    Also, at some stage, I was hoping to port Eleven's source code from raw BASIC 65 form into Eleven source as well, so that Eleven can compile itself one day, and so that other users can more easily comprehend the code and contribute fixes. That journey is still a work in progress, but you're welcome to study the "11.parse.el" equivalent, if it helps make things easier :-)


    https://github.com/MEGA65/eleven/blob/main/11.parse.elpc

    I had a look into the code but I didn't find a reason for the issue regarding to COLLISION... until now.

    But I found the reason for my reported issue on github: my version of ELEVEN doesn't compile my source code because RGRAPHIC is an unknown command. And in the 11.PARSE.BAS file that command is missing =O. My version is from the Mega65 Filehost. May that version a little bit old?

    Yes, ubik's final version is a few years old now, and was missing some basic commands (which I tried to add in the newer version whenever I or others noticed they were missing).


    So yep, definitely worth giving the newer version on github a try too:


    https://github.com/MEGA65/eleven/raw/refs/heads/main/11.D81


    At some stage, I was hoping to make a new release of the changes I added, though presently, I haven't done much testing if the changes I added potentially broke any prior projects, so I feel it needs more time to mature before a formal release.


    Hopefully you'll be able to tweak 11.parse in some way to get it working.


    I had quick look at "11.parse.elpc" now, I think the area to scrutinise is inside .pass_2 where I see a for loop that iterates over each destination line string. An inner for loop aims to break the string up into tokens and assess if any are labels that can be swapped out, withe the call to .swap_out_label_in_cur_tok$_for_lineno


    I guess something has gone astray here in relation to COLLISION, so could be a good point to add some extra debug print output there and assess what is amiss.