Posts by ubik

    Der Typ war echt - wie man nun so sagt: "todeslost"

    Das allergeilste war ja seine Selbstdarstellung in seiner nächsten Firma (die er mit seinen Söhnen zusammen betrieb, inzwischen nur noch via archive.org zu sehen):


    https://web.archive.org/web/20…rtners.biz/principals.htm


    Quote

    His prior experience includes serving as the President of Commodore International, where he accomplished a major operational turnaround.

    ROFL, ja, klar, so kann man es auch ausdrücken...!

    Actually, there is not really such a thing as "C64 mode".


    Unlike the C128, all of the MEGA65 features are available in its C64 configuration. And I mean all of them. Full speed, full RAM access, all VIC-IV features, all 4 SIDs, enhanced opcodes, 32-bit-addressing, everything.


    The only difference is that C64 starts in a more developer friendly memory configuration and has the C64 kernal banked in.


    Of course you can try remain in C65 configuration and call C65 kernal functions, but keep in mind that it's a hell of a lot more complicated and there's really no benefit, as both C64 and C65 kernal call the same CBDOS routines in the end.


    In fact, I suspect, someday the C65 'closed ROM' will vanish into oblivion anyway, as soon as the Open ROM evolves and gets a nice programming language.


    (yep, I completely understand why one would want to 'remain' in C65 mode... once I thought so too ;))

    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? ;-)

    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.