Posts by FeralChild

    It's been a lot of fun, but at the end of the day I think the MEGA65 would really benefit from a little more modern implementation (think: BBC BASIC...) of the language; because BASIC10 is essentially slow, unfinished and unstructured (yes, we have do-loop, begin-bend and all that stuff, but: still no named procedures/functions, all maths are slow and floating point based, variables have only two letters, etc. etc.). But of course, that's only my 2ct ;)

    Believe me, developing a new ROM is also fun. Plus, the MEGA65 native mode ends up working the way you want it to work - so I can only encourage you to help with development of such BASIC, link in my signature :D

    @mega65 Would something like this be reasonable? Instead of calling the normal reset routine, just do JSR ($FFF8). Unfortunately, it touches byte $8000 (RAMTAS - to detect cartridges limiting available RAM), but it restores it's value afterwards. It does some mapping, but it only maps memory below $8000.


    Regarding F1 - function keys can be redefined in the configuration file before the compilation ($27 + 'X' can be set too); currently it's a little bit harder (contrary to KickAssembler, ACME does not support string variables), but I'm going to make it easy again using other method. I don't know yet what the final defaults will be (current settings are temporary), but a lot depends on the feedback from users :)

    @Paul

    1. I haven't noticed it, the pre-generated PDFs from just a few days ago does not have them :) I have looked into the LaTeX source, seems to be complete, but... @LGB-Z just wrote, that DMA cannot cross 64K boundaries; I can't see this documented anywhere, and this is a serious limitation (the chunk of data can't be larger than 64KB, this is obvious from the DMA list format).

    2. So maybe it would be OK to ship older version as a part of bitstream, but provide newer one as the file on SD card?

    3. 80x50 is the default now in the latest version - that's why I would like it to being shipped, to immediately show the DevKit users what we can achieve if we implement custom ROM taking advantage of MEGA65, and not only the C65.

    I wasn't aware of the special function of F1 - but I'm definitely not going to implement it this way:
    - using a single key shortcut for something so destructive that it involves clearing the screen seems like usability nightmare to me
    - users of expanded C64s typically expect F1 to execute some useful command - like, for example, listing the disk directory (depending on their favourite cartridge)
    - the C128 uses ESC followed by X to switch between modes; I think for the next generation Commodore-like machine it would be wise to follow this convention, ESC-X could cycle through all the available modes (40x25, 80x25, 80x50) - I just don't have the escape codes implemented yet

    @LGB-Z I'm not going to use chained lists - I have made a note to reuse the modulo bytes. The $F is probably the result of memory location never initialized; in fact, after switching from C64 mode any value can be present there (depending on the screen content). I'm going to put 0 there for the FILL job, allowing flags to have a random value is probably not a good idea anyway.

    Actually, the job is intended to do something different:
    - command here is $0B, which is FILL ($03) + yield to interrupts ($08) - AFAIK the $08 is not implemented nevertheless, I will remove it if I decide it's unsafe

    - the $01 value at $5F8 is intended to be a fill value (here - a code for white colour), not a part of any address; bytes $5F1, $5F9 and $5FA are uninitialized garbage - I expect them to be totally ignored by the DMAgic engine

    - the target address is $FF80000 (bytes $5F3, $5FD, $5FC, $5FB), which is a MEGA65 colour RAM - I need more than 2KB accessible at $1F800

    - size is $2800 (bytes $5F7, $5F6), or 128*80 - currently our virtual screen has 128 rows (so that our text console takes exactly 10 KB of screen memory + 10 KB of colour RAM - long story... these might change, depending on future graphics support in BASIC and feedback from the users)


    Option $80 (bytes $5F0, $5F1) is supplied only because I reserved one piece of memory for the general purpose DMA list, pre-initialized as much as possible. This way routines 'm65_dmagic_oper_fill' and 'm65_dmagic_oper_copy' (which are intended to be general purpose) have a little less work to do, they just:

    - set the command code

    - adjust the source/destination addresses by some bit shifting, so that $80/$81 options specify the megabyte, and $5FA/$5FD contains only 4 bits of addresses (for FILL only the destination address is adjusted - that's why we have $F8 in $5FA)

    - trigger the DMA job


    Right, the DMAgic documentation is hard to get. MEGA65 chipset reference describes the enhancements done in detail, but does not describe F018A/F018B lists. I have chosen F018A because I see no use for the subcommands, and the blog post I got a lot of information from ( https://c65gs.blogspot.com/201…controller-interface.html ) discuses the F018A format.
    If F018B allows to skip the address adjustments (provide just the 4 bits by $80/$81 options and remaining 24 bits of address in the DMA list itself), or there are some other benefits - I'll migrate to F018B.

    adtbm Sorry for hijacking the thread, it wasn't intentional.

    I was testing using branch https://github.com/hernandp/xemu/tree/megawat - and it does not complain about the modulo at all.

    But I see you dev branch indeed does complain - I have tried to clean the modulo to 0 once again just before launching the DMA job - but it didn't help. Strange... Also, your branch does not seem to support 50 rows of text, just 25 are visible; and I haven't implemented switching between 80x50 and 80x25 yet, so it's a little bit hard to use this branch for testing. [edit] And it does not support $D064-$D065 (pointer to the start of colour data within the colour RAM) - without this, the scrolling won't work (I'm using 80x128 virtual screen, user can scroll upwards - for example, to see more lines of code, or disk directory entries which would be lost on CBM machines).

    If the latest release (https://github.com/MEGA65/open…d996c913f598c5593024b/bin) works correctly on the real machine - than I suggest to deliver this one. 99% of the changes was the introduction of new text mode, after GO 64 it should behave almost exactly as the previous version.

    If the 80x50 text mode causes problems - the build from previous merge request should be stable: https://github.com/MEGA65/open…2868ae88a5597f6981a66/bin

    Definitely don't wait for the next merge from my branch. What I'm now working on, is migration from KickAssembler to ACME - there will be no functional changes (just few small optimizations here and there), but the risk of regression is quite high; this is about 40000-50000 lines to migrate, features of both assemblers do not match exactly 1:1, there was a lot of boring and error-prone manual work to be done.

    Not that easy. Spending 5 minutes with each game is not enough - one has to make sure every cutscene, bonus stage, boss, "game over" stage, "you won" stage, etc. works correctly. That saving/loading high scores (and/or game state - but this is rare for C64) works correctly. With both C64/C65 ROMs and Open ROMs.

    Than FPGA core and/or Open ROMs has to be improved for the compatibility. Sometimes the piece of software would have to be patched - to be able to use 40 MHz mode, work from the internal drive, etc. And once every single production is handled, one would have to do all the testing once again, to make sure there is no regression. With current manpower - probably enough work for several millennia :D

    Ok, 80-column screen editor merged, can be downloaded from https://github.com/MEGA65/open-roms/tree/master/bin . Remarks:

    - you need XEMU with VIC-IV support; I'm using megawat branch from hernandp

    - editor provides roughly a C64 editor feature set + a "virtual console" - you can scroll back (upwards) up to certain point
    - MEGA65 rom now starts in MEGA65 native 80x50 mode (unless a C64 cartridge is inserted - recognized by the standard CBM80 string), you can manually switch between modes using GO 64 / GO 65 commands
    - SYS command switches to legacy C64 compatibility mode; to avoid the switch use GO SYS command (initially I intended to introduce a new keyword, NSYS - but I wanted it to be easy to produce "fat binaries", where BASIC code detects whether it is C64 ROM, C65 ROM, or MEGA65 Open ROMs, and launches machine code part using appropriate start address)
    - to detect MEGA65 + Open ROMs (in both native and legacy modes) from BASIC, do IF MEGA65 GOTO ... or IF MEGA65 THEN ... - this is actually a hack, MEGA65 is not a tokenised keyword (neither it is a variable, only the IF keyword checks for this particular string), it will display correctly even in CBM BASIC 2.0 editor; on BASIC other than Open ROMs on MEGA65 it will be considered as checking ME variable and (unless ME has non-zero value) the condition will evaluate to false
    - switching between modes preserves program in memory, but clears the variables - for MEGA65 native mode I am planning to move the variables from the usual place to MEGA65 extended memory area, clearing the variables is just a preparation
    - loading anything below $0800 (read: autostart software) should switch to legacy C64 compatibility mode (but this is currently totally untested)

    Last, but not least: THIS IS STILL A PROOF-OF-CONCEPT - MEGA65 native mode memory map might change, BASIC extension described above might change, etc.

    Great, so I don't have a problem with DMA lists.

    There is one more thing, for which I might need to introduce a workaround - I'm quite sure 40 MHz will break the current IEC protocol support. AFAIK both Turbo Chameleon and Ultimate 64 have a workaround: once the IEC-related ports are touched, the CPU speed returns to 1 MHz for the next 1000 cycles - this way both the Kernal IEC implementation and just about every disk turbo can still function properly. Is there something like this planned for MEGA65 (I don't know if it would be compatible with C65 ROM), or should I always switch to 1 MHz for the IEC access?

    We'll see what's the opinion of Paul.

    In MEGA65 native mode we don't need to be fully compatible with anything - if the official way to use RS-232 or IEC with VIC-IV flexible addresses feature is to completely disable hot registers, than MEGA65 native mode will run with disabled hot registers 99% of the time (or maybe even 100% of the time), and I'll re-enable them again when switching to legacy/compatibility mode.

    From Open ROMs point of view - this is not a serious problem. If legacy software is detected (cartridge with CBM80 signature, autostart software loading below $0800, or machine code launched using SYS command instead of native NSYS - these should probably cover 99% of cases), I simply switch (or will switch, as not all these mechanisms are already implemented) to legacy compatibility mode, where VIC-IV features are disabled, we have 40x25 screen starting from $0400, etc.