1. What about the code license?
2. Are you using C65-based ROM or Open ROMs as a base?
You are about to leave Forum64 to get redirected to the following address:
1. What about the code license?
2. Are you using C65-based ROM or Open ROMs as a base?
I expect 99% of problems with games is caused by XEMU / MEGA65 not simulating the C64 hardware perfectly - not due to ROM compatibility problems.
It’s just a side effect of C64 mode Kernal not aware of the VIC-III and VIC-IV registers, and unable to properly switch to 40 columns mode. I don’t think it is a good idea to use tricks like that.
The last time I tried, the 1541 emulation part of the Ultimate-II+ was working, but I was unable to get into the cartridge menu. AFAIK the DMA cartridges are not supported yet, so there is no chance for it to fully work (REU…), besides the MEGA65 IEC support is currently not too compatible (for example, JiffyDOS won’t work properly yet).
ubik Ultimate-II+ is much more than just 1541 emulation. It can emulate 2 drives, they can be nicely expanded (you can use S-JiffyDOS ROMs), it simulates the Datassette, REU, geoRAM, some cartridges, it even simulates IEC printer. I can see Gideon is experimenting with 1571 and 1581 emulation too ( https://github.com/GideonZ/1541ultimate/commits/1581 ).
There is no chance for MEGA65 to provide all this in the near future. True, we can handle D81 images, but the internal drive is not compatible with 1581. And 1541 is not there yet.
OK, good to know. Should be usable, although there are some challenges:
1. IRQ and NMI interrupts redirectors will be needed in the additional bank(s).
2. Various pieces of code in both Kernal banks will have to be aligned; the current Open ROMs build system (we have quite a sophisticated tool to determine routine placement - to stay compatible in key places, and to fill-in remaining gaps in efficient way) does not support this, it will have to be extended.
3. I'll probably have to be careful what the Open ROMs build system puts into $e460-$e49f range - it would be best not to waste the whole area.
Background: if you start the Ultimate 64 (or MEGA65) Open ROMs build, you'll see 51199 BASIC BYTES FREE - because the BASIC memory ends at $cfff, not at $9fff. Therefore, $e000-$e4d2 is a very precious ROM area, as I enforce memory access subroutines to go there - they typically work in a scheme:
- unmap the $a000-$bfff BASIC ROM
- do in the RAM whatever is needed
- map the ROM again
This way I can provide 12KB more RAM to BASIC, and the performance penalty is likely to be very small.
Is the test firmware available to download somewhere? How do I construct this special CRT file? Nevertheless, it will take some time before I can start working on this, I would like to finish the current 'sprint' of MEGA65 internal DOS improvements first.
1. I’m afraid the Ultimate II+ might be problematic with native MEGA65 software, as it does not know about VIC-IV video modes, so it might be unable to display it’s menu and restore the previous video settings. I could already see the IEC part of this cartridge working, though. And keep in mind, that 1541 drive simulation using images on SD card is planned for MEGA65 at some point. D81 images can already be mounted to the internal C65 drive controller.
2. True, the C65 ROM has tape routines removed. Bringing them back for C64 mode can be challenging, I’m not sure how much space is left in the C64 part of the ROM. One option for the user could be to switch the ROM set to original C64 one. AFAIK ROM switching is currently being worked on by someone.
On the other hand, Open ROMs already has code for loading software from tape (normal and TurboTape 64, with file formad autodetection and a built-in head alignment tool) - but without saving and using data files (OPEN, GET#, etc. mechanisms won’t work). See
@Bulli_ I perfectly know how it looks like, this is my GitHub page after all Of course the additional switches couldn’t be connected in the same way - I mean a separate connector for accessing them, available for future extensions only.
[Maschinenübersetzung] Bulli_ Haben Sie darüber nachgedacht, eine MechBoard-Variante für die modernen CherryMX-Tastenkappen herzustellen? Der fehlende 9U-Speicherplatz kann umgangen werden - Sie können einen 6U-Speicherplatz und zwei 1,5U-Spezialschlüssel verwenden, deren Status über zusätzliche Pins lesbar ist. Diese zusätzlichen Tasten können von verschiedenen Erweiterungen verwendet werden - z. B. durch Drücken beider Tasten, um den C64 zurückzusetzen, das Ultimate 64-Menü auszulösen oder das Disk-Image im internen SD2IEC auszutauschen.
[english] Have you considered producing MechBoard variant for the modern CherryMX keycaps? The missing 9U space can be worked around - you can use a 6U space and two 1.5U special keys, with state readable via additional pins. These additional keys could be used by various extensions - like press both of them to reset the C64, trigger the Ultimate 64 menu, or swap disk image in the internal SD2IEC.
Till now I haven' used the .Q register a single time as of yet, and .Z is of limited use - not many addressing modes use it. Honestly, I would prefer to have LDA [...], Y, but not limited to zero page for the pointer, and a more efficient MAP, not trashing every single register.
But that's me, my use cases are rather specific
Actually, I would prefer .Z register to stay 0 all the time, it causes portability problems as described above. One of the reasons I've decided not to reuse Commander X16 DOS after all.
Actually, I'm tempted to use TBA as a replacement of LDA #$00 in the ROM, but I'm a little bit scared
It will probably take a few years to finish the MEGA65 FPGA core too - there are still a lot of incompatibilities, features planned to implement, and so on. And with BBC BASIC this also won’t be that simple to just port it - the graphics/audio will have to be redesigned to support the MEGA65 hardware, the core will have to be adapted to support extended memory, and so on.
Named functions / procedures shouldn’t be hard to implement. As for local variables, you would need a completely new variable subsystem - which would be a good idea nevertheless, as the 128KB of RAM above 0x40000 is currently unused when running BASIC.
Just keep in mind, that floating point routines are not finished as of yet, this is probably the hardest part still left to be implemented.
Then why not to finish and extend the current Open ROMs BASIC instead? We don’t have to stick to 2 characters long variable names in MEGA65 native mode, we can have a completely separate variable model there, maybe even more types of variables.
I believe few active developers could come with a reasonable BASIC in a reasonable time. BTW. When I’ve started my work, I didn’t even remember how to compare two values in 6502 assembly
Yes, I know block is 254 bytes (not 256 bytes), I'll fix it
Well, I actually intend o purchase few C64 games (definitely the Pig Quest!), but mainly to support the idea of retrocomputing, I don’t expect to spend too much time playing them. I’m probably too old to come back to Narnia.
As for MEGA65, I currently see no game I would like to purchase. In the future - who knows.
I agree open-source is generally a better idea, but for some reason this idea does not work for games.
Why crazy? Both C128 and C65 have two separate BASIC interpreters. My idea (to use same interpreter, but with changed behavior in the native mode) has both advantages (less work needed, porting software to native mode would be easier), and disadvantages (harder to improve the language, lower performance). My choice was partially due to lack of manpower (someone has to write the Kernal and internal DOS too; I'm really happy I could integrate the BSMON, so that we now have a monitor in ROM), I wanted a way to re-use the current code. If someone has a different idea and actually wishes to spend time on it - well, sometimes the plans do change
Currently, Open ROMs autoswitches from native mode to C64 compatibility mode if it encounters a SYS command (to prevent this, one has to use GO SYS) - but we can change this behavior; it might recognize the 'modern BASIC' software by some magic sequence at the beginning (for example, $01, $00 instead of the start address). This shouldn't be a big deal, although it will require some work within the Kernal to handle loading properly.
One of the problems I have (which will limit the performance) is that I need to constantly alter memory banking - so that I can fetch data from below the BASIC ROM. A fully dedicated native mode interpreter can work differently - store BASIC program above $40000 (we have at least 128 KB there, some future models may have more) and only use flat memory access for text and variables. This way we could bank-in the whole modern BASIC interpreter (well, at most 40KB actually, which is still a lot) and only handle banking when doing Kernal calls (but the performance hit on these wouldn't be noticeable 99% of the time).
By “project” I meant BBC BASIC port/reimplementation - somehow (after reading the discussion on the RISC Open forum) I think you will be left with the second option only...