Zitat von FeralChild

Would it be possible to make $DD00 hot ONLY if writing to it changes bit 0 or 1?

That was my first thought too, but for me, it looks like there is not "best" solution. As CPU can write only bits for real. Yes, what you say makes sense, to detect bits 0,1 written are the same or not. However that may creates a problem that a legacy program want to set VIC-II bank and it turns out the same as bit 0/1 already in DD00 and already VIC-IV specific precise address is used, then that request would be ignored Quickly it becomes very unclear when it works and when it doesn't. I think it's more clear solution to disable HOTREG feature first, if this wanted to be used. But also I am not sure what's the best thing to do in this case .......

I see, however a change like this (change = the proposed change to trigger hotreg event only if bits 0/1 are not the same as they were) affects anything not just OpenROMs, since it's kinda of a beheviour of the hardware itself (in FPGA). At the other hand, this $DD00 is kinda interesting, maybe (as far as I can mention now ...) the only thing which is considered "hotreg" other than an actual VIC register. But honestly I see problems with both of the behaviours in some respect ... For OpenROM, maybe you should disable HOTREG behaviour as whole, if not needed, then you don't have surprises Though for sure you need to turn back on for some compatibility with existing software using VIC-II specific video mode/etc settings ...

Zitat von FeralChild

We'll see what's the opinion of Paul.

In MEGA65 native mode we don't need to be fully compatible with anything - if the official way to use RS-232 or IEC with VIC-IV flexible addresses feature is to completely disable hot registers, than MEGA65 native mode will run with disabled hot registers 99% of the time (or maybe even 100% of the time), and I'll re-enable them again when switching to legacy/compatibility mode.

That sounds like a good approach in my opinion, but indeed, I am not the right person for making hardware decisions about MEGA65.

Zitat von FeralChild

@hernandp Would it be hard to implement the 48MHz mode bit (VFAST - bit 6) in the $D054 register (VIC control register C)? I expect, that running from V2 BASIC:

Code

1. POKE 53295, 71: POKE 53295, 83 : REM UNLOCK VIC-IV
2. POKE 53332, 64 : REM set VFAST bit

should switch the system to 48MHz.

Isn't that working? It should work even in "baseline" Xemu since "ages". Btw, I guess it's not actually 48MHz, more like 40 currently (though I'm always unsure what is the current fast clock exactly, hmmm).

Oh, by the way, there're special rules for that D054 bit 6 to work. Hopefully it's the same with real MEGA65 but I implemented in a way what was "I was told" back then, ie it only works if the CPU is already in C65 FAST (or at least C128 fast, I am not sure) mode, otherwise setting that bit has no effect. See mega65.c in Xemu source code, machine_set_speed() function where it's a switch/case construct of combinations of "speed bits" and the result. So it's not directly controlled only by that bit, but actually a combination of three speed specific bits are considered (not even counting the POKE 0,65 stuff ... which is kinda a brute force and simple method to force M65 fast mode in any way) to set the actual machine speed. Though I am not sure if it's the correct behaviour I emulate, maybe it's not the same policy any more in mega65-core?

And one thought: I am not sure if user guide contains this information, but maybe it would be important to have a section dedicated to CPU speeds, effects, timing, how to set up, even mentioning the danger of NMOS timing for compound ops (OK, it's already there, but I mean it's important to mention at this section as well, I think!). Since it can be confusing if someone expects setting bit 6 of D054 causes M65 FAST without any additional requirements.

Zitat von FeralChild

These special rules are not documented - if you search the current MEGA65 Chipset Reference document for VFAST and D054, you'll only find a simple description: C65GS FAST mode (48 MHz) - so I was expecting this should be enough.

I'm not sure if I correctly understand the machine_set_speed() function - besides it has several TODO and FIXME comments. I'll just create a new ticket for this in the user guide repository.

Yes, I always mark TODO/FIXME if I have even a faint thought that I am not sure it should be done this way Worse: I sometimes left those comments there. So you'll find those basically everywhere But the important point of that function is using three bits of various registers (C65FAST, M65FAST and C128FAST) to form a 3 bit value and use that in switch/case to basically enumerate all the combinations and what it will cause. M65FAST alone does nothing, still 1MHz, unless C128FAST and/or C65FAST is also set. If I remember correctly, and implemented correctly, and the mega65-core hasn't yet changed this behaviour

Since I think, it's not 48MHz but really 40MHz ... Honestly I cannot tell the exact fast clock, but I *think* it's 40 or so for real on MEGA65 as well. It varied throughout the lifetime of the project because of various timing constraints and development. Btw, even user guide mention 40MHz everywhere now. Though I've also noticed that iomap.txt talks about 48MHz, probably that's remain from the past (and also Paul told me, that I should not rely on iomap.txt too heavily in general ...).

EDIT: Ok, it seems to be confusing, the user guide itself mentions 48MHz indeed, twice. But all other mention of fast mode talks about 40MHz Actually you can set any fast clock with Xemu with the -fastclock option, though the question here, what is the exact fast clock currently on a real MEGA65 which should be the default in Xemu without that option As far as I know, it's 40MHz.

MEGA65 "full speed" mode is currentl 40.5MHz, but subject to change.

LG

Paul.

Zitat von FeralChild

It seems that XEMU does not implement bit 6 (CROM9) of the $D030 (VIC control register A). Same problem with MEGA65 DevKit (see bug report https://github.com/MEGA65/mega65-core/issues/309), also Open ROMs builds incorrect image not providing a character set at $9000 offset.

I'm aware of that (in case of Xemu), for a long time mega65-core did not implement this either and (IIRC) solved the issue to double the size of the character-rom storage (which is not really the ROM, but an other part of the memory). I was not so keen to care, since it seems in official ROMs the C64 and C65 charset are the same. Or at least I remember as they are, but I am not sure now :-O Implementing this Xemu should wait now, since it needs to alter the global memory mapping also maybe needs a more decent hyppo to initialize (though in theory that can be "tricked") otherwise the "wom" (write-only memory from the view point of the CPU, used as chargen ROM for real by VIC-IV) won't be initialized. However a decent Hyppo update currently won't work with Xemu because of many missing things to be implemented and/or changed in the design of mega65-core since then.

However that's interesting you tell mega65-core has problems with this, AFAIK it solved the problem already, just Xemu does not emulate that change. Hmmm.

Zitat von FeralChild

Zitat von LGB-Z

I was not so keen to care, since it seems in official ROMs the C64 and C65 charset are the same. Or at least I remember as they are, but I am not sure now :-O

AFAIK they are not exactly the same, it's like with C128, where native mode has slightly altered lowercase 'i' (possibly also other tweaks, I don't remember). Open ROMs has 2 slightly different character sets too - the one intended for native mode has some bugfixes, VENDOR+N and VENDOR+M are actually different, etc.

I believe you, but still the reason isn't - of course - this one not to implement in Xemu right now, but the other things. But indeed, of course that a missing feature must be done some time ... Probably near the time when merging VIC-IV stuffs from Hernan's experiments and my ongoing other changes. Anyway I've booked a new issue 213 in Xemu's issue page, so I hopefully won't forget this one.

MEGA65 hardware doesn't support it, and might not for a while, as it requires an extra BRAM. T100 based boards are unlikely to get support for it, due to this. So I'm inclined to just not implement it, since very little existing software (if any) depends on it.

LG

Paul.