Monitor is able to view VERA memory, but does not save to file

[Fruggs]

I wrote some code in BASIC to write to a palette, and looking for a lazy way to spin it out to a file that I can use BVLOAD later.

(I'm aware I could just write it out sequentially to a file instead or in addition to poking it in, but I want to be lazy)

Thought I'd try using the monitor but it looks like it's not saving from VRAM.

Reproduction:
1. Mess with the palette (tokenized EGAPALETTE.BAS will do)
2. Enter the monitor, enter some commands (a sample is included in the picture)
3. The output data looks way off from what the memory view showed (attached as SAMPLE.RAW inside the zip file, sorry, can't attach raw files)

Running on the emulator, haven't tried on hardware. I'm not sure where the data comes from, but the sample doesn't match the display at all.

[ahenry3068]

I wrote some code in BASIC to write to a palette, and looking for a lazy way to spin it out to a file that I can use BVLOAD later.

(I'm aware I could just write it out sequentially to a file instead or in addition to poking it in, but I want to be lazy)

Thought I'd try using the monitor but it looks like it's not saving from VRAM.

Reproduction:
1. Mess with the palette (tokenized EGAPALETTE.BAS will do)
2. Enter the monitor, enter some commands (a sample is included in the picture)
3. The output data looks way off from what the memory view showed (attached as SAMPLE.RAW inside the zip file, sorry, can't attach raw files)

Running on the emulator, haven't tried on hardware. I'm not sure where the data comes from, but the sample doesn't match the display at all.

You might want to look at my game HANGMAN
viewtopic.php?p=30065#p30065
I threw the Kitchen Sink at this one. Among other things I did a Wysiwyg Palette Editor in BASIC into the mix.
It's a separate program from the main game. It's written using BASLOAD format not line numbered but it
is in BASIC.


There is a PAL2FILE subroutine in the Palette Editor.

paleditor.png (14.13 KiB) Viewed 301 times

[ahenry3068]

Also. I don't think you can directly view VERA ram from the monitor.

VERA Ram is accessed through a single DATA Port address and is not mapped to the main processor address space.

[desertfish]

If you use the alternate emulator Box16, you actually can inspect VERA ram and then some. It provides a plethora of different monitoring and debugging windows

[jaydg]

Also. I don't think you can directly view VERA ram from the monitor.

VERA Ram is accessed through a single DATA Port address and is not mapped to the main processor address space.

The K command lets you select a vram bank but I don't know if save/load respect that.

[Fruggs]

You might want to look at my game HANGMAN
viewtopic.php?p=30065#p30065
I threw the Kitchen Sink at this one. Among other things I did a Wysiwyg Palette Editor in BASIC into the mix.
It's a separate program from the main game. It's written using BASLOAD format not line numbered but it
is in BASIC.

Can't get easier than a tool already written! Thank you!

Also. I don't think you can directly view VERA ram from the monitor.

VERA Ram is accessed through a single DATA Port address and is not mapped to the main processor address space.

Admittedly I didn't check all 512 bytes of the palette area, or the greater VRAM in general, but from the small 32 bytes I checked out, it looked like a match. That I might have gotten lucky and found a section of main RAM that had those same values doesn't seem likely.

If you use the alternate emulator Box16, you actually can inspect VERA ram and then some. It provides a plethora of different monitoring and debugging windows

Is this the one you mean? https://github.com/indigodarkwolf/box16
Will it work with the current ROM release? Looks like it's matched with r41 instead of 48

[DragWx]

When you READ from VERA 1:F9C0..1:FFFF, you don't get the contents of the register, but rather the last byte written to that address by the CPU. On a cold boot, those values are unpredictable even if the registers themselves are initialized.

This information comes from here, the VERA chapter of the docs, the very end of the VRAM address space layout section.

I don't know that this is what's happening, but here's how you can check: Try writing some bytes to the palette, then dump the palette memory. Does the dump show unexpected values except for the bytes you wrote? If so, then that's what's happening. If everything is wrong, then it's a different issue.

[ahenry3068]

When you READ from VERA 1:F9C0..1:FFFF, you don't get the contents of the register, but rather the last byte written to that address by the CPU. On a cold boot, those values are unpredictable even if the registers themselves are initialized.

This information comes from here, the VERA chapter of the docs, the very end of the VRAM address space layout section.

I don't know that this is what's happening, but here's how you can check: Try writing some bytes to the palette, then dump the palette memory. Does the dump show unexpected values except for the bytes you wrote? If so, then that's what's happening. If everything is wrong, then it's a different issue.

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) .. Before that came about I just made sure my code initialized them on program start

[jaydg]

Will it work with the current ROM release? Looks like it's matched with r41 instead of 48
--

When I built it locally I used 48. Have had no issues.

[DragWx]

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.