Hallo Besucher, der Thread wurde 6,6k mal aufgerufen und enthält 31 Antworten

letzter Beitrag von adtbm am

MEGA65 DevKit - small update ;-)

    Hi all !


    This is a small update/inside look into one of the minor tasks in such a project as the MEGA65 and here in preparation for the DevKits, have fun reading it ;-)


    While the whole DevKit is coming together absolutely nicely but with some extended hours for us...

    (We burn a lot of midnight oil* (*PGS)) Here is a small look into the tasks we're doing atm, besides, besides, besides the nominal work for the project ;-)


    I've unpacked and prepared (partitioned and formatted) 100 microSD cards with SD-Adapter for the DevKits.

    Beginning of next week, we will finalise the content for the SDcards and then we will copy the files onto the 100 cards and send them to our partner Trenz Electronic*

    (*Partner, Mainboard designer & manufacturer and prime seller).


    MEGA65 has to format and prepare all 100 SD cards for the DevKits.

    Using a modified formating tool (Thanks Paul for FOLTERLOS), based on the Built-in SD formating tool inside the MEGA65.


    100 SD cards :-) ...for the DevKits !!!


    It's a shame how much trash comes along with just 100 cards. I will reshape and reuse the plasticparts and we'll look into something different for the final MEGA65.

    Which one would you suggest ?

    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.

    Hi FeralChild !

    i forwarded this question to Paul. i think, i'll give both OpenRom versions a try tonight myself.

    But thanks for your suggestions !

    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).

    Well, that's the strange part, that DMA should not have any difference between the two branches ... Yes, for sure, VIC-IV emulation enhancements haven't been merged back yet from Hernan, that's true, so it won't help you. But here I was only interested about this DMA warning which shouldn't make any difference too much. However that modulo problem should come from the DMA list itself, depending on F018A or F018B DMA format, subcommand byte bit 0 and bit 2 for F018B, or from one of the high bits of source and target addr in case of F018A format. I have no idea what DMA format you use, though I can try to hack Xemu to print the DMA list in question what it is actually when it reports that ... Well what I wrote which byte/bit, now I wrote those by heart, so ... :)

    OK, here it is for you, hopefully I haven't done any major mistake on analizing the output ...



    So it seems to be an enhanced mode DMA which specifies option $0A, aka "use the F018A format" for the DMA list itself.


    IIRC now really, I cannot find a good description of the DMA list composition anymore, so I have to follow my very ugly code in Xemu:


    So the combined value for source is: $F80001 and target is: $080000. The problem here, that in case of F018A both of source and target 24 bit values actually holds special bits at the very top four bits, and those are not really part of the address. If I remember correctly the top 4 bits meanings in case of F018A formatted list:


    bit23 : operation is I/O memory, instead of "normal" one

    bit22 : negative direction of the DMA (inc or dec of address)

    bit21 : MODULO must be used.

    bit20 : hold (no inc/dec of addr)


    As for you the source highest nyble is $F, all bits are set, thus even MODULO. I mean the $F8 byte there, and the nyble of $F from that, being bits bits 23:20 from the formed 24 bit addr. As I can see, the $F value seems to be strange anyway.

    To summarize, they key things (again IIRC):


    1. DMA cannot cross 64K boundaries

    2. F018A format though have 24 bits for source and target only 20 bit counts, so you can do DMA with sources within 1Mbyte range

    3. You can specify the megabyte though with enhanced options to any of the 256 possible megabytes (thus MEGA65 has 256Mbyte address space), so you have 28bits, the lower 20 bits are specified with the lower 20 bits of source/target addr in the F018A format source/target itself, the upper 8 bits can be specified with enhanced mode MEGA65 specific DMA options

    4. the four remaining bits of source/target for F018A format are special so signal things, I've described above, they are NOT part of any address itself!

    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.

    Right, I like to use F018A format as well, since shorter :) Also, if you don't use modulo (which should be the case as MEGA65 does not support it, IMHO) you can even omit the two last bytes, even if the DMA controller read two bytes at the end it won't be used. BUT it's a dangerous game, if you use chained entries, of course you must include them, you can only omit them, if it's the final or the only DMA list and no chained one after it. Maybe it's not even a good practise to do it so, as we can easily forget later if it becomes a chained one ...


    Anyway, the problem is at byte at $5FA as the lower 4 bits of that is the source address bits 19:16, however for the top high bites here is $F in your example, which would imply to instruct DMA controller to use modulo for the source, I/O memory access, etc. Which does not make sense, I think. My question, why it's set to $F.


    The same is true for the $5FD for the target, but here is no problem as in your example it's $08, so there is no problem there ($0 for the top four bits which has special meaning - those are the meanings I told with that bit23,bit22,bit21,bit20 "table" I meant that for the bits of the "virtual 24 bit length address" constructed from the three bytes of source and address, of course it can be read as bits 7,6,5,4 of the highest byte of the source and address).


    And INDEED (and it's my fault to started to talk about other thing here!), it would be better to move this thread to somewhere else :) I have no idea how to do it, or even if I have rights to do it (I guess, no ...).

    Howdy folks,


    A few notes:


    1. I have expanded the DMAgic documentation in the MEGA65 Book, so that the DMA list format is now properly explained for both A and B revisions. Please let me know if anything important is still missing.


    2. The main issue for advancing to latest OpenROMs in the bitstream is that the flash menu uses the built-in ROM *and* executes in hypervisor context. This means that you can't use MAP in any of the setup code in OpenROMs, or it will de-map the hypervisor causing no end of halarity. OR OpenROMs needs to to somehow notice that it is in hypervisor mode, and know to restore the memory mapping after.


    3. I think 80x50 would be great to use as default mode. Do you also plan to implement F1 to toggle video modes, as on C65 BASIC 10?


    LG

    Paul.

    @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.

    We haven't generated new PDFs since I made the changes, so you would currently need to typeset them yourself, or read the latex source directly.


    I'm fine regarding your decision with F1 vs ESC-X. I agree that pressing F1 is a bit too easy to do by mistake.


    I'm more interested in us finding a way that can work for the flash menu use-case. Any ideas you might have on this would be very welcome. Bonus points for a solution that avoids using any space in the HYPPO ROM. This could be, for example, an entry point into your KERNAL that does the necessary setup calls, and then restores the Hypervisor memory context via MAP instructions (I can supply code for that).

    LG
    Paul.

    @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 :)