Posts by ubik

    Don't know about the Ultimate-II specifically, but:


    - the MEGA65 already includes a Freezer Menu which lets you select the disc image. Currently .d81 images are supported (as the C65 had a built-in 3.5" drive), but 1541 support is also planned.


    - the 1565 (==internal drive of the C65) was already many times faster than a stock 1541. The MEGA65 is even faster when accessing disc images. While not as fast as the SD card interface could be, it's on par with current fast loaders.


    As for cartridges: Some work, some (currently) don't, but it's constantly being worked on. But I think once the MEGA65 is finished, there will be no need for the Ultimate-II cartridge.

    Bit Shifter has made (and is continuing to make) many small and large enhancements to BASIC10, which are in their entirety now called BASIC65. But although some of the advanced features of the MEGA65 (such as enhanced DMA and 32 bit addressing) are supported in BASIC65, it’s not really supporting the new modes and capabilities. Think of it more as an urgently needed bugfix to the mess that Commodore has produced with BASIC10.

    One thing this thread has definitely done: There is now an Acorn Electron here. :D

    Hey, welcome to the Acorn party :)


    I'm the proud owner of this beauty here:



    And although this Master Turbo is 10 times faster and has a SD card adapter builtin, I'd still like an Electron for my collection because I quite like its design :) Also that big mean ULA that's running half of the Electron could be seen as a distant cousin to the ARM processor since it was the last thing that the team designed before moving on to processors...


    Alone before the BBC BASIC 2, I really take off my hat! What here - also "under the surface" - of really good thoughts are in it, all my greatest respect! I prefer to spare myself a comparison with BASIC 2 from the C64. ;(


    It's amazing, isn't it? Imagine what would have been possible if Commodore put something even remotely like that into their computers... ;)


    (we should take care not to talk too much about these things, otherwise adtbm might cut the heating to our cabins and make us renumber 5000 lines of BASIC2 spaghetti code by hand as a disciplinary measure!! ;)))

    Hier: Mensch mit normaler Morphologie; Maschinenschreiben im 10-Finger-System vor 30 Jahren mal professionell gelernt, schaffe im Schnitt um die 300 Anschläge pro Minute, wobei das beim Programmieren natürlich kaum mal vorkommt. Habe drei Monate mit dem MEGA65-Prototypen (*nicht* dem DevKit) verbracht, während dieser Zeit yaped32 und die Anfänge von Eleven darauf entwickelt und dabei keinerlei Schmerzen empfunden oder mich sonstwie an irgendwas gestört.


    Das einzige was mich irgendwie ein bisschen stört, ist dass immer wieder irgendjemand irgendwas mies machen muss und man die Sache nicht einfach mal gut sein lassen kann.


    Ferner:

    Kann ja sein dass ich das alles viel zu naiv sehe, aber ich sehe bei diesem Projekt ganz einfach sehr viel nette und fähige Leute, die mit großer Leidenschaft etwas auf die Beine stellen und immense Freude daran haben. Und das find' ich persönlich sehr schön.


    5. Menschen, denen es Spaß macht

    6. Menschen, die näher an der Maschine programmieren und sich nicht durch AppStores, Signed Applications und sonstige Gängeleien quälen wollen

    7. Menschen, die mal kurz vergessen wollen, wie vermurkst, durchreglementiert und unkreativ Softwareentwicklung in heutigen "agilen" Zeiten geworden ist

    Once again, I was not talking about BASIC10 and/or the closed ROM:


    But my question was not relating to BASIC10 at all. It's true that BitShifter has made tremendous fixes and enhancements to BASIC10, and he deserves nothing but the highest praise for that... but the fact stands that BASIC10 is (and always will be) a woefully inferior implementation of the BASIC language (which btw is one of the reasons why I wrote the Eleven development system).


    Yes, I know, many folks want to keep it there to "keep the C65 feeling" and "be true to the original" and "be compatible to the 5 BASIC10 programs that already exist", etc., etc. pp., and that's completely fine and good and understandable I wholeheartedly support that notion, and I don't have anything against it, and as far as I am concerned it may stay there forever... but I also very much would like a modern implementation of BASIC on the MEGA65, and I think the platform would *greatly* benefit from something that doesn't rely on floating point math, two-letter-variable names and line numbers, all of which were anachronisms in 1992 already.

    and the original poster wasn't either:


    PGS is okay with it, so I don't think it's an issue. I'm not doing any Kernel work at all, save a very simple interface to the hardware. Nor is it an extension, nor is it remotely binary compatible, though it is pretty much text compatible. It can't be completely so. This is in some ways a good thing ; Paul was very keen that it shouldn't be based on the available Microsoft BASIC source and things like the Floating Point Arithmetic are completely different. The whole implementation is different ; it has nothing from it at all.

    So all I wanted was to inquire if this project was still alive (regarding its MEGA65 port) and whether help is needed.

    Basic 10 is being worked on (and currently named Mega65 Basic on the newer ROM’s) by Big Shifter.

    The Basic examples in the manual are indeed not all working and some outdated. Since last week I’m in the process to validate each single Basic example in the manual and correct them when needed, or have them corrected by Big Shifter as he exactly knows the changes in the Rom.

    So yes, MEGA65 will have an improved Basic 10 with up-to-date examples in the manual.

    The latest manual will already have some examples fixed.

    Thanks, I'm quite aware of that. In fact, I played a little role in it.


    But my question was not relating to BASIC10 at all. It's true that BitShifter has made tremendous fixes and enhancements to BASIC10, and he deserves nothing but the highest praise for that... but the fact stands that BASIC10 is (and always will be) a woefully inferior implementation of the BASIC language (which btw is one of the reasons why I wrote the Eleven development system).


    Yes, I know, many folks want to keep it there to "keep the C65 feeling" and "be true to the original" and "be compatible to the 5 BASIC10 programs that already exist", etc., etc. pp., and that's completely fine and good and understandable I wholeheartedly support that notion, and I don't have anything against it, and as far as I am concerned it may stay there forever... but I also very much would like a modern implementation of BASIC on the MEGA65, and I think the platform would *greatly* benefit from something that doesn't rely on floating point math, two-letter-variable names and line numbers, all of which were anachronisms in 1992 already.


    (sorry if I sound a little bit irritated, but I have been writing this for over six months now... :alt:)

    Quite astonishingly I have been lobbying for a new MEGA65 BASIC for six long months now, but I haven't been aware of this project previously (in fact I mistakingly thought it simply related to the BASIC of the Open ROMs)...


    So I have a few quick questions:


    Is this still actively developed? If yes, how‘s the MEGA65 port coming, and do you need any help with it? Because MEGA65 needs you :)


    Great advancements have been made fixing and enhancing CBM BASIC10, but it's at its heart still a convoluted, hazardous and archaic affair.


    I still think it would be absolutely wonderful to have MEGA65 ship with the choice of 1) the fixed version of original CBM BASIC, and 2) a beginner-friendly, powerful and modern implementation of BASIC.

    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

    If it runs through. ;) It‘s a simple kind of unit testing, so the screenshot above is a bad result =O


    When you see --- TESTS COMPLETED. --- at the end, everything is ok. Like so:



    If it breaks before that, there‘s a bug. In your case, the DS$(x) bug (you can DIM and use DS(), you can DIM DS$(), but you can't actually use DS$(x), it always has the contents of DS$... this was incidentally fixed by BitShifter a few weeks ago and then cropped up again later and is now fixed again ;))


    You can type LIST to see the failed test, RUN to repeat it, or rename it (e.g. RENAME "T095-RESNAMES1“ TO "X095-RESNAMES1") to disable it. The tests are (and should be) quite simple. They're written in a way that they STOP when an unexpected result is discovered, thus breaking the chain of tests that the RUNNER program is executing.


    I thought about displaying the elapsed time at the end but decided against it, your benchmarks are much better for that. This is only for testing and seeing if there are regressions.

    Hi all,


    here is a (small but growing) BASIC65 test suite:


    https://files.mega65.org?id=76317380-7c96-485c-8dc1-837c26b5ae3a


    Bit Shifter & me are currently using this to find & narrow down bugs in the BASIC65 interpreter. It would greatly benefit from more tests covering more of BASIC65's various aspects.


    So, if you're feeling like adding some tests, the suite is easy to extend. Simply save a test routine with the filename T@@@-TESTNAME (where "@@@" is a three-digit decimal number) onto the test disc and make sure that your test routine ends with DLOAD "RUNNER" (or breaks in case of an error or unexpected result). If in doubt, have a look at the existing tests for examples.


    To run the test suite, simply BOOT the disc. Tests are being run in the order of their numeric ID.


    If you have written any cool (or boring ;)) new tests, feel free to send them to me, so that I can add them to the disc image.

    Then why not to finish and extend the current Open ROMs BASIC instead? We don’t have to stick to 2 characters long variable names in MEGA65 native mode, we can have a completely separate variable model there, maybe even more types of variables.

    If we also could have

    • named multi-line procedures,
    • named multi line functions and
    • local variables

    in there, I might really, *really* be tempted to bite the bullet and reacquaint myself with 6502 assembly... :)

    Dear Richard, first of all, many many thanks for your efforts! They are greatly appreciated.

    I very much hope that all of the above allows you to feel you can proceed with the project.

    It's enough to make a private project out of it.


    But, as Snoopy says:

    In this respect, he urgently advises against bundling the BBC BASIC (6502) in its present form with another open source project. This can also drag it into the jumble of rights and ultimately endanger it as a whole.

    With this state of things BBC BASIC will most likely never become an officially blessed & bundled programming language for the MEGA65, because the risk of dragging the project into all kinds of legal BS is just too high... and so it will not be able to do anything towards the 'simply switch it on and start doing great stuff with a great programming language' user experience I had hoped for.


    It really hurts me to say this, and it's frustrating the living hell out of me (remember, I was the one suggesting porting BBC BASIC in the first place), but that's the way things are.


    Luckily, there are at least two alternatives that also don't look half bad. But learning from this experience I'll probably ascertain their feasibility first this time, instead of getting people excited.


    (all just my personal views of course)

    So it seems that the banks > 0 can just be used for storing/loading some datas in/from it but not for running a program in it?


    E.g. if I have a program in bank 8 I of course want that a STA $02 saves the content of the A register into $02 of bank 8 and not into $02 of bank 0. :)


    You would have to use the MAP instruction to map the corresponding 8kb block of the desired bank to bank 0 (but I've never tried this in conjunction with the base register... in theory it should work; I'd like to write a little demo but I'm just too tired for the MAP instruction at the moment... ;)


    OR, you could use zero-page indirect addressing [ NOP + LDA(ZP),Z ] to access any 32 bit address directly, without the hassle of having to deal with the MAP opcode.