This is the starting place for reporting bugs to the team. We will pass bug reports on to the developers after validating the reports.
You can report bugs in hardware, operating system (KERNAL or BASIC ROMs), the emulator, or the Demo library. For bugs specific to downloaded programs, use the download forum.
ahenry3068 wrote: ↑Tue Nov 05, 2024 7:31 pm
I don't know about the rest of the memory. But somewhere around r45 they did start initializing the Palette Ram on boot so those should be reliable. (512 bytes starting at 1:$FA00)
I thought so too, I double checked, and it does, so that's not the issue.
The problem seems to be simpler: the monitor uses the plain Kernal LOAD and SAVE routines for the L and S commands. The monitor hardcodes L to always load to system memory (not the VERA), and SAVE can only read from system memory anyway.
So, while the monitor can be used to dump the contents of VRAM to the screen, there doesn't seem to be a way to use the S command to dump VRAM to a file.
You yourself would need to copy your data out of VRAM and into system memory first, then you could save that to a file.
There's been a lot of discussion on that particular issue. SAVE can't save from Video Ram because you can't tell it an ending access since all VRAM is read through one of two data port address's. So there isn't an ending address. I've got a VRAM save both in BASIC and Assembly and TallLeRoy (on DISCORD) wrote a routine for Prog8. It's not hard to save VRAM it just doesn't fit in with the system Save routine.
SAVE has a couple of shortcomings. One of them is the inability to save from VRAM, but another is the inability to save from banked RAM.
That is, when you LOAD to banked RAM, it automatically handles wrapping from $BFFF to $A000 and increasing the RAM bank.
SAVE doesn't have any knowledge of banked RAM and will just naively walk the address space.
Such a SAVE routine would need to use a starting address and a byte count, rather than an absolute start and end, and that byte count would need room for 17 bits, plus one more parameter for specifying VRAM or not. I'd also say saving from banked ROM should be supported as well, which would need an 18-bit counter.
DragWx wrote: ↑Wed Nov 06, 2024 3:02 am
SAVE has a couple of shortcomings. One of them is the inability to save from VRAM, but another is the inability to save from banked RAM.
That is, when you LOAD to banked RAM, it automatically handles wrapping from $BFFF to $A000 and increasing the RAM bank.
SAVE doesn't have any knowledge of banked RAM and will just naively walk the address space.
Such a SAVE routine would need to use a starting address and a byte count, rather than an absolute start and end, and that byte count would need room for 17 bits, plus one more parameter for specifying VRAM or not. I'd also say saving from banked ROM should be supported as well, which would need an 18-bit counter.
It's an extra step but you Can use SAVE to save ROM or Hi-Ram, In it's entirety. It just takes a little extra code. SAVE has the capability to Append to a file rather than overwrite it. So you just have to do the Bank Wrapping in your own code.
