Hello, Guest the thread was called733 times and contains 10 replays

last post from Gurce at the

How to load data from disk into higher memory location

  • Just a q relating to one stumbling block I feel for my desire to convert my c64-sf2-reu port to mega65.


    Presently, my makefile just prepares a data.reu file (containing sprites, music) which vice can drop straight into reu memory.


    Not sure which path to take to get something similar for mega65.


    Will I need to instead drop the data.reu file onto a .d81 image and write a routine to copy it into upper memory?


    Any existing examples of similar things I could take a peek at?

  • Ok, think I might've located some clues inside the mega65-ide application, on how it loads source-files into upper memory for its the editor:


    Think the point of interest is inside "buffers.c" - buffer_load():


    Code: buffers.c - buffer_load()
    1. while(!feof(f)) {
    2. r=fread(data_buffer,1,256,f);
    3. ...
    4. buffer_set_bytes(buffer_id,file_offset,r,data_buffer);
    5. ...


    That function turns out to be a macro that calls buffer_getset_bytes().


    Inside it, there is a call to "memory.c" - lcopy():



    Aah ok, the penny is dropping, use dma to copy it into upper memory.

  • Ok, I've dabbled with this dma-copying technique tonight, with mixed success. I tried copying just 128-bytes of my loaded data into bank1 (0x0010000), that seemed to arrive there fine, well, kinda, maybe its offset by one byte.


    Anyway, I tried writing more data beyond this point, and eventually got things freezing up, with all the text in a funny colour...


    Ok, a penny dropped that the c65 memory map consumes the first four banks of 64kb (0x0000000 to 0x003FFFF). So I tried copying to bank4, 0x0040000 but all the memory there remains at just "FF FF FF FF .." values afterwards.


    Wondering if I've overlooked something that's preventing this copy from working? Or is this a bad location to do such copies to?

  • I'm not progrsammar, but as far as I understood the documentation in the preliminary manual, there are some techniques which can confuse in dealing with memory.

    First: the microcontroler itself manages up to 1MB RAM with own build-in MMU.

    Second: the DMAgic (REC) manages up to 8MB.

    As far as I understand, the DMAgic moves content from microcontroler-RAM (aka CPU-RAM),to REU (the 8MB).

    And of course also back from REU to CPU-RAMspace.

    As far as I understand the microcontroler (CPU) can't read nor write directly to RAM in REU (similar like in C128: CPU can' read/write directly to REU).

    DMAgic (REC) only moves data between RAM Expansion and CPU-Mem.

    Well all that is of course for C65-Mode. Don't knw what Paul made availlable for MEGA-Mode ;)

    So first of all, we need to define what we might call 'higher memory'. (For me it is the 8MB DMAgic manages), and 'low memory' (this is in my opinion the RAM that the 4510 can directly access (with his build-in MMU).

  • MEGA65 has extended support for the MAP opcode and also for DMAgic to access the full 256Mbyte memory space (in fact for DMAgic, even the possibility to operate according F018A and B, since there are two different revisions of that chip and they're incompatible, some - older - C65 ROMs and software use the revision 'A', newer ones wants 'B'. Also MEGA65 has other options over C65's DMAgic, like "transparency" thus while copying data, do not overwrite a given byte at the target if the source byte is a given value, nice to copy screen areas which should have transparent pixels ... Also, there are fractional steps, which can be even used to scale a texture). I'm not so familiar with REC (IIRC it's called REC in C65 - Ram Expansion Controller), but as far as I can see, it's more easy to just use the MEGA65 way of DMA and CPU's MAP support (also REC would not allow to access 256Mbyte RAM anyway, and have other limitations as well).

  • Ah ok, previously, I had been testing this dma-copy in xemu. Now I'm wondering if there's a difference of behaviour between xemu and the hardware in some way.


    I set up my old nexys board for a comparison.

    • Checking my nexys-board's bitstream version, it's pretty old (build GIT: sept18,f4d2b39,20181007.13)
    • Checking my copy of xemu, it is also fairly old (de0e5725d from 17/02/2018.)
    • I should probably update these versions soon, as things might've been repaired in future versions.
    • But anyway, I'll test with what I've got right now
    • I ran m65dbg/serial-monitor for both systems, and tried to write to that 0x0040000 address in both, but with different results:
    On Nexys Board In Xemu
    <dbg>m40000
    :00040000:00000000000000000000000000000000

    <dbg>s40000 ab

    <dbg>m40000
    :00040000:AB000000000000000000000000000000

    <dbg>m40000
    :0040000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
    <dbg>s40000 ab
    <dbg>m40000
    :0040000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF


    So it seems like writing to this address on the real hardware was permitted, but it wasn't in xemu?


    Also, I noticed this point in the c65manual:


    They've defined bank 4 to 7 as 'reserved' for future cartridges. By reserved, I suppose that could be construed as meaning "please don't touch this area of memory, it's not permitted", or it could also possibly mean, "yeah sure, you can fiddle with this area of memory, but don't blame us if one day some cartridge poopoo's all over your data".


    Personally, I'm not sure which interpretation of 'reserved' is the reality here.


    Anyway, I'll at the very least try to update xemu to a newer version and see if it fares any better.

  • I would suggest to update Xemu first, it's hard to tell what's going on, if it's really an old version. In fact, older Xemus does not even emulated more memory than 256K (128K RAM and 128K "ROM" with the later can be used as RAM as well on M65 in contrast of C65). The extra 128K (thus 384K of "fast" RAM, ie FPGA block RAM) was not even emulated by Xemu in older versions yet, maybe that is the problem? The other possibility that simply the monitor does not work too well, and for real what you wrote is there, just it's fault of the monitor interface you use with m65dbg that you can't see it. So in nutshell, I would really suggest you to update xemu, especially if it's older than some weeks (which is the case, I assume). This is likely the problem, as for C65, there won't be anything after $40000 too much, but you will have RAM there on MEGA65, however it wasn't the case some time ago even with MEGA65 (when the fast RAM size was increased from 256K to 384K, which was then followed by Xemu to emulate this change).

  • Cheers Gabor, yep, I'm trying this approach now. Trying to figure out how to make the transition from my old 2018 mindset to how things roll now.

    • Back then, I would use the -newhack argument, but studying the code, I see that's no longer needed, so I've removed
    • I've had trouble locating the "uart.sock" file. Will keep sniffing around, but maybe you can point me in the right direction quicker than I find it? :)
  • Cheers Gabor, yep, I'm trying this approach now. Trying to figure out how to make the transition from my old 2018 mindset to how things roll now.

    • Back then, I would use the -newhack argument, but studying the code, I see that's no longer needed, so I've removed
    • I've had trouble locating the "uart.sock" file. Will keep sniffing around, but maybe you can point me in the right direction quicker than I find it? :)

    Yes, the "newhack" stuff is the default now, back to then it had some sanity as there were older Hyppos (sorry kickstart was it called back to then ...) which used the old DMA behaviour, but since then everything is based internally on the enhanced DMA list, what that "newhack" means. Thus, there is no need for this anymore.


    For the uart.sock stuff: honestly I haven't even tested/used that since "ages". It was removed to be used by default, HOWEVER in theory at least you can re-enable with a switch: -uartmon and you need to give a file name, so you can use any name not only uart.sock, also maybe directory where you want to put that named socket, etc etc. For me (and other people had some issues with this as well) it was kinda ugly Xemu to always "spams" every directory with this socket, even when most people don't even need this. Surely, if you often depend on this, you may want to put this into the configuration file, so you don't need to specify all the time "by hand" as a command line argument (surely, it's true for all Xemu command line switches, btw).


    Also "nice to know" category still: with decent Xemus now you have UI menu (right click into the emulator window), probably the most important value of this, to allow to change external D81 image run-time. Though, if you compile xemu at your own for Linux, then you need libgtk3 devel stuff installed for this able to work (on windows and macos, the GUI popup stuff uses the native GUI API, so there you don't need extra component).

  • Thanks for the explanation :) Yep, the monitor is working much better now, after I used your latest xemu and added the argument "-uartmon uart.sock".


    For the example memory edit, it now behaves much better:


    <dbg>m40000

    :0040000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

    <dbg>s40000 ab

    <dbg>m40000

    :0040000 AB FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF


    Happy with that. Yep, sounds like what you described before, my version of xemu was so old, it didn't emulate memory above 256kb, good to know :)


    Thx again :)