When mounting a disk image from the Freeze menu, I can navigate into subdirectories, but there's no way to navigate to a parent directory. Moreover, if I Run/Stop to return to the Freeze menu then try to mount a disk image again, it starts in the subdir where I left off. I have to completely exit the Freeze menu then re-enter it to reset the working directory to the top level of the SD card.

Let me know if I'm just missing something. :)

Core 20221008.23,2f545d1. Freeze menu v0.2.0.

Hi there!

I just heard about you recently, and I'm already hooked. I HIGHLY appreciate that you are making this open-source. As a developer, I admire all serious projects that are going open-source.

I can see that you are continuosly working on the platform and the code, since it updates the repository update dates. As I can see, you are getting very close on finishing it. Can you please give me some kind of percentage progress?

Much thanks,

Omer Shamai, on behalf of the entire vintage computer community.

Currently a rebuild of freezer is done by M3wP so refactoring the existing freezer is not required anymore.

This aims to do the following:

• check Makefile for problems
• add stubs for mega65-core submodule integration (reuse of common components such as cc65)
• add build files to .gitignore so that they don't clutter git status
• merge common functions of all routines
• fix #27

My tests with the issue #168 bitstream showed:
That the freezer menu is not reflecting the changes. When selecting 1MHz, machine is in 2MHz, when in 2MHz, machine is in 1MHz.

Also the C64 mode starts with 2MHz now instead of 1MHz how it should be
(No issue created at this time in the mega65-core repo)

After changing into a subdirectory, I can't go back into the above folder.

The MEGAINFO tool should be rewritten in C/ASM and put into the Freezer (HELP or V?) as MEGAINFO.M65

It should be able to extract version strings from all M65 tools on the SD (#39 )

See https://discord.com/channels/719326990221574164/805492126128930846/992272795100794891

If the ROM charset is changed, it might be difficult to read it...

Would be nice to embed a short string into these *.M65 files (a bit like the git commit info string we put inside our core files).

In time, this could hopefully make it easier for us to assess what versions of these things a user presently has, and later we could update the MEGAINFO tool to extract such info out of these *.M65 files too.

simple mixup in format_datestamp starting with august.

I had today time to fire up newer bitstreams and newer roms. I do see following issue.

1. Power on Mega65
2. go into freezer and mount geos disk
3. reset with f5
4. go into freezer again showes strange values for drive assignments

Used Bitstream: development branch(development@3503b1a), build 159 on devkit R3
Used ROM: 920281.bin
Used Freezer: V0.1.4 (downloaded from release-prep-repro 03.01.2022)

FREEZER.zip

Update: I do see the same/similar issue with the game Solitair.

Refers to MEGA65/mega65-core#499

request by deft. especially when switching slots (this is the "read ok" border black from hal sd read).

Like the freezer already has a sprite editor/viewer, it also would be nice to have a simple FCM Tile Editor.

(migrated from mega65-core/issue#117)

I did add M65THUMB for M65 mode in b1533e0

This should be removed for the next release build of mega65-core, and M65THUMB should be made standard.

the sprite editor seems to break sprites in recent versions.

reason is that the fetch/store functions in frozen_memory.c are not working correctly for unaligned, non sector length (512) data.

On r3a (and r3) with core development@fc504ef I get the following behaviour.

• Boot into onboarding disk (release-prep@15e21d6)
• Hear nice title music.
• Freeze
• call Mixer
• master vol left to -8db, master vol right to -8db, F3, F3
• listen to music
• Freeze
• call Mixer
• master vol left to -16db, master vol right to -16db...
• sometime it freezes at exactly the point where you try to change right here
• sometime I need another iteration of unfreeze/freeze/mix

Steps to reproduce:

• launch the ROM: https://github.com/MEGA65/open-roms/blob/6223f90e9c55f11076e599984504a8e9aaa9a326/bin/mega65.rom
• enter freezer menu by holding RESTORE
• result: garbage on screen

Freezer works correctly in Open ROMs legacy mode (GO 64 command). I have tested, that it's the $D068-$D06A manipulation by the native mode breaks the freeze menu; when I commented it out, the freezer displayed proper screen.

Holding the RESTORE key for 1s for the first time does not bring up the freeze menu. Only after doing this once and then doing it again will in fact bring up the freeze menu. From that moment onward the feature will work as advocated until the machine is reset (soft or hard) at which point it will take one extra hold-for-1-second before it works again.

If you change the video mode (PAL/NTSC, CRT emu) in freezer it will change the selected slot.

When you then go on and change the slot and start it, this slot will have the old settings (whichever was saved).

A user would expect that after changing mode and then selecting a slot, this slot should resumed in the newly selected mode.

Probably it is not using the D81 track/sector mapping that was implemented?

Freezing LUMA, TOXIC FRENZY or current GEOS will result freezer in

a) Not being able to save to freeze slots
b) display garbled thumbnails, even for already existing ones (in fact always the same garbled one is shown)
c) being unable to mount a new disk image
d) possibly more...

Tranferring an issue from the core branch for handling reset from within freezer menu:
MEGA65/mega65-core#72

Instant lockup on pressing RESTORE with attached disk image
Nov_demo.zip

It would be cool to be able to extract freeze states from an SD card as files, and install freeze files into slots.

mega65_ftp has a getslot command to download a freeze slot. Apparently there isn't a putslot yet, so this issue requests one.

While browsing asubdirectory with D64 images, there are some fragmented files inside. First it will show the error, and keep showing the next unfragmented directory, but after the second or third fragemented error display, every image (even ones that were show before) will fail with an 88 File not found.

Leaving the subdirectory and entering it again will fix this and display can happen again... until you encounter to much errors again.

Perhaps a problem with open files and/or not unmounting mounted images?

~/MEGA65/mega65-freezemenu$ make >z
ld65: Warning: Duplicate external identifier: _i' ld65: Warning: Duplicate external identifier: _i'
ld65: Warning: Duplicate external identifier: _i' ld65: Warning: Duplicate external identifier: _value'
ld65: Warning: Duplicate external identifier: _i' ld65: Warning: Duplicate external identifier: _i'
ld65: Warning: Duplicate external identifier: `_value'
make: *** No rule to make target 'C65THUMB.M65', needed by 'all'. Stop.

You can select a ROM and try to load it, and this will cycle the border color, but after returning to the FREEZER, regardless how you leave, you will be still at the old ROM.
(Tested with master@16518d8)

Write $FF to $DC00 and $DC02 is required.
Otherwise keyboard input can be disabled in freeze menu

With freezer (release 1.5, 30 Jan 2022) on my Mega65 I have an issue with D81 images. If I create a new image inside the freezer and then use DirMaster (Windows) to copy a single file to that image, the image is unreadable inside the freezer, no content is displayed and the border color changes to brown(?).
From this moment on, all D81 images are unreadable, I have to leave the disk menu and reenter to select a different d81 file.
I attached an example image with some simple binary data file (a sid file).

MEINS.ZIP

As per discussions on discord here:

• https://discord.com/channels/719326990221574164/719326990221574168/823524182012198932

In mega65-core's "iomap.txt" file, the 4 SIDs get referred to with this terminology:

C64 $D400-$D40F = right SID #1
C64 $D420-$D43F = right SID #2
C64 $D440-$D45F = left SID #1
C64 $D460-$D47F = left SID #2

I have the following suggestions:

After studying the behaviour of the audio mixer in the freezer menu, I drew a mental picture that formed of my understanding of it:

With that formed understanding, I'm feeling it's better if we were to remove these 'LEFT SID' and 'RIGHT SID' group names, as they are red-herrings.

E.g. Depending on how you choose to adjust things in the audio-mixer, you could make the 'LEFT SID' group play its output on the RIGHT channel.

So I suggest we abandon those 'LEFT SID' and 'RIGHT SID' group terms and just call them what they really are, either "SID1+2" or "SID3+4" (if we were to name the SIDs as SID1, SID2, SID3, SID4).

I think the file we'll need to tweak in here is called "freeze_audiomix.c".

It'd also be nice if we locate the file responsible for the output in mega65-core's "iomap.txt" and update it with this new terminology also, to make things consistent.

If I can squeeze some time in to look into this, I will. But if anyone else has the appetite for it, you're welcome to it.

The MEGA65 memory system has many layers and backwards compatibility features, and it is often confusing to understand the current state of the system. I would love an interactive utility that can visualize the current state of memory mapping. Some things an interactive utility can help explain:

• BASIC 65 BANK state, including the special ROM and I/O mapping behaviors of BANK 128
• D030 banking
• KEY register
• Locations of relocatable VIC-IV memory regions
• Other MEGA65 ROM reserved memory regions, e.g. CBDOS and BASIC variable memory in bank 1

If I understand correctly, these are properties that are captured by a freeze state, and so it's appropriate for a freeze utility to offer this as a way to explore a freeze state. Other hardware properties may or may not also be useful (or possible) to represent in such a utility, such as:

• MAP registers
• The presence/absence of RAM expansions such as Attic RAM

I know MAP registers are not available in userland, and are visible in Matrix Mode. If a freezer utility can ask the Hyppo for these values, it could help illustrate the effect of MAP values in a way that Matrix Mode cannot.

I'm imagining this as interactive memory map visualizations. I would love to be able to zoom into address ranges and understand the "state" of a given set of addresses interactively. For example, the next time I forget that I can't POKE $8000,$BB in the default BANK 128 mode, I can open the utility and zoom to $8000 and the tool will visually explain to me what's going on and help me understand what I need to change. This will require some thought and iteration to capture common developer questions and use cases.

See subject; pressing RESTORE while already in Freezer, the systems seems to lock-up.

My personal preference for pressing RESTORE while in the Freezer, would be to do either nothing (key disabled) or same effect as F3 (return / close Freezer).

feature request: please update screen after save (F7), like using cursor left and right.

BASIC10 lacks an in-built sprite editor compared with BASIC7 on the C128. Therefore it would be nice to build a sprite editor into the freeze menu.

See mega65-user-guide/issues#434

When opening freeze menu (after reset) and opening disk selection through either 0 or 1, the list shown only contains 'no disk' and 'internal 3.5"' or '1565 drive 1', not the d81 images. Pressing RUN/STOP to back out and entering the menu again solves this from thereon.

With recent build the NTSC screen is shifted down by a fair amount. D048 and D04E are obviously wrong.

The idea stemmed from confusion over terms like 'digi left' and 'digi right' and how they both appear in both the left output and right output groups of the 'simple view' of the audio mixer.

In this discord convo, Paul suggested a path forward to make the 'panning' intent more obvious to the user:

• https://discord.com/channels/719326990221574164/782757495180361778/824053433098043455

Another option is to change the mixer display, have the control for the SIDs and digi channels instead be volume level + panning, instead of showing separate left/right output levels.
Then the left/right names won't be confusing in the same way.
The total number of items would stay the same, but would have a more logical gain/volume level for each item, and then below that as a group, the stereo/panning properties could be listed as a group

There was also some discussion on a potential algorithm to perform this volume+pan mapping to two L/R volumes:

GurceYesterday at 10:25
Ok, so perhaps to implement a volume+pan control, there'll need to be some modest algorithm to map these volume & pan values to the two separate left+right volume controls for the channel. That sounds palatable too, and it'd make the 'simple audio mixer' view even simpler.
gardnersYesterday at 15:37
Yes, so basically I'd make the centre point be -6dB on each side, and having something fully right/left will be -0dB for the selected side and -24dB for the otherside. Intermediate values would then be interpolated between these.
There is already the code there to set a channel in -dB, so it would just be making the nice slide-bar thing, and then translating that into the updated settings.
Conversely, when reading the current mixer values you have to interpret them in this framework, or if it can't be interpreted sensibly, then just set the panning to centre and the appropriate output level.
(note the -dB values above are relative to whatever the output level for the channel is selected at.
This means when reading the mixer values, you have to work out what the non-reduced audio level would be, based on the difference in levels between the left and right outputs.
You can simplify it by only allowing, say, 15 different panning positions in the audio mixer, and having a table of the -dB modifiers for these.)

Attempting to enter the freeze menu when a standard 16k ROM cartridge is inserted causes the system to lock up (see attached photo).

I've determined that this is due to the freezer accidentally accessing the cartridge memory (ROMH, I think). This only happens when the GAME line from the cartridge is held LOW (thus enabling the cart's second 8k of ROM to be visible). An 8k cartridge seems to be fine.

The fix for this is to disable the cartridge and force EXROM and GAME back to 1 when initializing the freezer. I have a PR coming for this very soon.

the logic for USE_LOCAL_CC65 does not work as expected.

Refer to MEGA65/mega65-core#220
This repo is used as a submodule in MEGA65-core.

The fix has been identified,
refer to: MEGA65/mega65-fdisk#5
which s also a submodule of MEGA65-core.

When real floppy is selected as Device 8 in Freezer, and Device 9 is left empty, the floppy drive works as expected.

However, when at the same time a D81 is selected as Device 9 (see screenshot) and I do DIR U8 (floppy) the result is "74, drive not ready,09,37".

Above works fine when I mount the floppy and D81 via DOS/BASIC.

Config:
Core 20220525.13, 9bf9798
Freezer 0.1.4
ROM 920355

If possible please replace "garbage titles" with "unnamed task" as well (not only empty ones). Possibly check for char >127 to be in the string as they mostly contain inverted etc characters. Thanks :)

OK, I was about to post a screenshot of the Sprite Editor, trying to draw a circle (key o), but I found that the SE reacts actually very randomly.
I cannot draw circles, at best it draws a rectangle, but most of the times the background of the sprite as well as the coordinates (right corner) and PIP (middle right) just starts flashing.
Happens both on the release core and latest core, both with most recent Freeze menu v0.1.9

Update: same with Freezer 0.1.4

simple as that, lost in refactoring...

Updating the process descriptor is done in the freezer. It should happen in hyppo instead.
If the internal drive is attached, this is also not detected. But it seems ffd36a1 is cleared in frozen memory and also after exiting the freezer again.

linked to mega65-core#619

The freezer and many of its utilities switch to NTSC and/or switch off CRT emulation on entry.
These should be preserved.

Spawned from discussions in this thread:

• https://www.forum64.de/index.php?thread/90784-map-instruction/&pageNo=2

Paul explained that the serial debugger does convey info on the currently mapped 8kb blocks via the upper 4-bits of MAPL and MAPH.

Perhaps the freeze monitor can build upon this in some way, maybe through better visualisation of what is presently mapped, or permitting the user to modify the current mapping on the fly and learn through trial and error the consequences of doing so :)