Posts by FeralChild

    I/O space mapped in - for once, additional problem is that there are various personalities of the I/O space: VIC II, VIC III, VIC IV, Ethernet. Now, try to map another part of the ROM, call the routine which didn't fit in the base ROM, and then restore the old memory layout - that would became really complex (and make the ROM very slow).


    I'm only glad that the original C65 ROM messes a little with MAP/EOM itself, so at least for the disk I/O the software has to be prepared, that it's memory mapping might get overridden.

    If you are extending the instruction set, maybe it's a good time to think about a better MAP? For me, the ideal one:


    - would accept 16-bit pointer to the structure in memory (RAM or ROM, depending on the current mapping), which would describe the actual map

    - would not touch or require touching Q (.A, .X, .Y, .Z), or the status register

    - would not require EOM afterwards

    - would allow to access whole Mega65 memory, without calling MAP twice


    Currently I need quite a lengthy helper subroutines to transparently change memory mapping: https://github.com/FeralChild6…_m65/mega65_map_helpers.s

    If I choose to implement it later, I'll need more memory than just 8KB (at least the amount needed to store 1 full track of 3.5" HD disk).

    In such case, it will be better to shift the screen memory towards $1F800 (if I understand correctly, above that we have colour RAM, not suitable for storing screen data).

    There is no DOS in my ROM nevertheless :D I just want to move screen out of the C64 address space, so that I have memory for additional features, like BASIC variable cache (I'll restore the C64 memory layout as soon as SYS command is encountered, or someone tries to load anything below $0800) - we can determine the best position later.

    @Paul - and what are your experiences with ACME? Looks powerful, but the manual is not too detailed. Unfortunately, writing for 45GS02 using KickAssembler is not straightforward - would it be OK for you if I decide to migrate Open ROMs to ACME too?

    The most important is, that the project attracted one more volunteer :)

    Are the Mega65 text modes reasonably well supported? I'm mainly interested in 40x25 / 80x25 / 80x50, with screen memory starting from $10000 (has to be outside of normal C64 address space), no extended colours or anything like this.

    Well, I probably someday I'll write graphic commands for OpenROMs too - but for now I'm stuck with string variables. Whenever I start working on them, I quickly find something else, that is so limited/outdated/irritating, that it needs urgent improvement :D

    I guess 80x50 text mode (1 colour per 8x8 cell) + graphics in the same colour would be very interesting too :)

    Actually, I would prefer to see a complete developer documentation first, than finished game. Unfortunately, the "VIC-IV" chapter has a lot of gaps, I'm especially interested in the Raster-Rewrite buffer - is it possible to have a 80x50 text screen as a complete overlay of a 640x400 pixels graphic screen (might be simulated by a text screen with 4000 user-defined characters)? Is it possible with the "16 colours per character" mode?

    That would be a great BASIC feature - to have the normal screen mode, and be able to draw on the screen that is behind it :D

    Snoopy - where did you get this information? The C64 mode in C65 is really not that much compatible, but Mega65 has quite a lot of improvements; supports 6502 illegal instructions, VIC-II timing is much closer to the original, if I remember correctly there are some workarounds here and there.

    MadZ28 - XEMU is a rather crude emulator, it is by no means as precise as VICE.

    But this way I would need to provide 3 files: BASIC ROM, Kernal ROM, and a CRT. And the user has to be careful to use matching versions of everything, or bad things will happen (screenshot). And - attaching a CRT means he can't attach any more cartridges, right? I agree, that utility carts probably won't work with OpenROMs for a long time, but game cartridges often work already.

    Just turn ON/OFF bit 4 at $01? OK, so I'll need address alignment between both Kernal banks, plus IRQ/NMI forwarding code. Could have been much worse :) For now additional 8KB is more than enough for me.


    Will it be possible to supply the alternative Ultimate 64 ROM without CRT image - just 8KB basic.rom file + 16kb kernal.rom file? This would be easier for the end user to handle.

    I see the 16k Kernal support got merged: https://github.com/GideonZ/154…4e38d26f9a61612c99db90f04

    Is the bank switching mechanism already decided? With the solution above I fear we could run into trouble if NMI occurs in the middle of memory access magic sequence.


    [Maschinenübersetzung]

    Ich sehe, dass die 16k-Kernal-Unterstützung zusammengeführt wurde: https://github.com/GideonZ/154…4e38d26f9a61612c99db90f04

    Ist der Bankwechselmechanismus bereits entschieden? Ich befürchte, dass wir mit der obigen Lösung in Schwierigkeiten geraten könnten, wenn NMI mitten in der magischen Sequenz des Speicherzugriffs auftritt.

    @Paul, I've got two questions:

    1. According to Mega65 Book, one can write 65 to $00 to switch the machine to full speed, and 64 to go back to 1 MHz speed. And it works under XEMU, my BASIC commands FAST and SLOW do exactly this. But is there a way to actually read the current setting? Sometimes (tokeniser - despite the optimization it is still slow in the worst cases, tape load, IRQ) I would like to switch to the maximum speed, but restore the previous setting afterwards.

    2. Last year you have shown a freeze menu monitor (https://youtu.be/WAlCLaKNoMk?t=296). Would it be possible to make it triggerable from the side of normal software? This way we could quickly implement MONITOR command in the open source ROMs :)