How to load data from disk into higher memory location

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

Quote from Freddy

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

Display More

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

Quote from Gurce

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:

• http://www.zimmers.net/cbmpics/cbm/c65/c65manual.txt

Code

1. 1.5.2. C65 System Memory Map
3. MAPPER BANK
4. -----+-----
5. |
6. |
7. 1M $F,FFFF +-------------+ ----------
8. | |
9. +- -+
10. | RAM | 512K BLOCK APPEARING
11. 768K $C,0000 +- -+ HERE IS DETERMINED BY
12. | EXPANSION | THE RAM EXPANDER CTLR
13. +- -+ (UP TO 8MB TOTAL MAP)
14. | |
15. 512K $8,0000 +-------------+ ----------
16. | |
17. +- RESERVED -+ FUTURE CARTRIDGES
18. | |
19. 256K $4,0000 +-------------+ ----------
20. | SYSTEM ROMS |
21. 128K $2,0000 +-------------+ SEE SYSTEM MEMORY
22. | SYSTEM ROMS | LAYOUT, BELOW
23. $0,0000 +-------------+ ----------

Display More

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.

Display More

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

Quote from Gurce

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