Thank you for your kind words It's great to be part of such a fun community.
I suspect the BASIC READY loop detection magic in Xmega65 might not know about the OpenROMs enough.
LG
Paul.
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von FeralChild am
Thank you for your kind words It's great to be part of such a fun community.
I suspect the BASIC READY loop detection magic in Xmega65 might not know about the OpenROMs enough.
LG
Paul.
Alles anzeigenFeralChild: Just wanted to say, a thousand THANKS for the awesome work you're doing for the Mega65 project! It is greatly appreciated (I also tried to post this as a comment on Paul's blog, but I have a feeling that blogspot's comment form doesn't play nice with my adblocker...)
On a related note, I'd like to try a few things with the Open ROMs. I can build and install them on my xemu-xmega65 without problems, but somehow once they're installed, I lose the capability of mounting .D81 images... is there any way around this or am I doing something wrong?
Kind regards,
Stephan
What happens exactly ie., what "lose the capability of mounting D81 images" means? Any error message, etc, console/terminal printout meanwhile, and so on? It is hard to tell if there is not enough input on the nature of the problem
Ah, ok!! That kind of explains everything
Well, I'll have to wait (even more feverishly!) for my Devkit, then
https://vimeo.com/452608177 - 80 column mode, work in progress
This looks fantastic! Are you thinking about being able to put variables etc into another RAM bank?
LG
Paul.
Variables, arrays - yes. And I would like to allow longer variable names, 2 characters is ridiculously little. But that's a distant future (we don't even have working floating point variables as of yet, only strings), and will be limited to MEGA65 native mode (that's why I'm already clearing all the variables when switching between legacy/native modes). To support something like this we need more space for RAM variables (including zeropage) for the 32-bit pointers, etc. - and in MEGA65 native mode I've gained quite a lot of easily accessible space by putting the screen within $1xxxx segment and dropping the 'dual logical line' concept:
- it would need quite some work to support above 88 characters in the tokeniser
- such a long lines of code would be hard to read nevertheless; even in "XXI century style" projects we usually stick to about 100-120 characters per line max, but we tend to use 4 characters for each level of indentation, we have quite long variable names, objects, API calls with 4 or 5 arguments, etc.; for CBM-style BASIC 80 characters per line is already a lot
As for the text (program), I don't have plans to move it anywhere - I want the program to be preserved when doing GO 64 / GO 65, and be able to easily fall back to legacy mode when user executes BASIC program looking like "10 SYS 2065". I would like to have something like procedures/functions in separate PRG files, or "chainloading" with keeping the variables intact - but again, that's a distant future.
I think the existing line length limit is fine at 88 chars, as you say. Putting variables and arrays into other memory banks strikes me as being relatively simple, in theory at least, as you can just use 32-bit pointers for their addresses, and use the ZP indirect 32-bit pointer addressing mode.
LG
Paul.
Well, it's not that complicated, but:
- it's a lot of work - the whole variable handling code (and this is quite a lot of code) has to be duplicated, one part using the 32-bit pointers
- expression parser expect 16-bit pointer to each string, same as each and every command - LOAD, PRINT, etc.; everything has to be adapted, and the 32-bit pointer handling has to be optional (configuration dependent)
- variable handling does a lot of memory copying; if the user adds a new variable, we need to copy all the array descriptors, string garbage collector copies a lot of memory too - it would be nice to use DMAgic for all this, and I'm not yet familiar with it (80-column screen editor does not use DMAgic yet). In particular, I'm not yet sure how it handles copying of partially overlapping memory areas ("which way" does it copy memory), it might be a good idea to actually reverse the order of memory layout BASIC currently uses - start from strings, afterwards a free area, then array descriptors, and variable descriptors at the end only
- in the future I would like to have a RAM disk with dynamically allocated storage - so we need to be able to effectively arbitrate memory usage between BASIC and Kernal, this has to be foreseen during development
And I think that after the 80-column mode text mode is stabilized and useable (there are still a couple of important things to finish), I'll take some time to move from KickAssembler to ACME. It doesn't look like we will see official 65CE02 and MEGA65 CPUs support in KickAssembler anytime soon, and with ACME syntax it will be much easier to integrate code like UP2400, UP9600, or the internal DOS from the Commander X16 ROM project (however, it seems their 2-clause BSD license is not compatible with LGPL 3 - so either we find some solution, or we will have to distribute the DOS as a separate binary).
ok. The MEGA65 book has some documentation on the DMA controller already, but let me know if you need more. It can copy in either direction.
LG
Paul.
I was able to find everything except one information.
Let’s assume a DMA job is running, set to yield to interrupts. NMI happens, handler realizes this is a STOP+RESTORE -> warm reset. How do I terminate this DMA job? It may wreak havoc in the system.
DMA jobs cannot be interrupted on the MEGA65 at present, so you never need to worry about this. Any interrupts triggered during the DMA job will be delayed until the end of the DMA job.
LG
Paul.
Great, so I don't have a problem with DMA lists.
There is one more thing, for which I might need to introduce a workaround - I'm quite sure 40 MHz will break the current IEC protocol support. AFAIK both Turbo Chameleon and Ultimate 64 have a workaround: once the IEC-related ports are touched, the CPU speed returns to 1 MHz for the next 1000 cycles - this way both the Kernal IEC implementation and just about every disk turbo can still function properly. Is there something like this planned for MEGA65 (I don't know if it would be compatible with C65 ROM), or should I always switch to 1 MHz for the IEC access?
Hello,
The C65 ROM has IEC code that works at 3.5MHz in C65 mode, I believe. The C64 mode code assumes 1MHz. We could implement something like that, as it does make sense for fastloaders etc. File an issue for me on github, and I'll have a think about how I might best do it. Probably will be based on changing any of the IEC lines, rather than arbitrary writes to the CIA.
LG
Paul.
Done. I think that's all for now
Ok, 80-column screen editor merged, can be downloaded from https://github.com/MEGA65/open-roms/tree/master/bin . Remarks:
- you need XEMU with VIC-IV support; I'm using megawat branch from hernandp
- editor provides roughly a C64 editor feature set + a "virtual console" - you can scroll back (upwards) up to certain point
- MEGA65 rom now starts in MEGA65 native 80x50 mode (unless a C64 cartridge is inserted - recognized by the standard CBM80 string), you can manually switch between modes using GO 64 / GO 65 commands
- SYS command switches to legacy C64 compatibility mode; to avoid the switch use GO SYS command (initially I intended to introduce a new keyword, NSYS - but I wanted it to be easy to produce "fat binaries", where BASIC code detects whether it is C64 ROM, C65 ROM, or MEGA65 Open ROMs, and launches machine code part using appropriate start address)
- to detect MEGA65 + Open ROMs (in both native and legacy modes) from BASIC, do IF MEGA65 GOTO ... or IF MEGA65 THEN ... - this is actually a hack, MEGA65 is not a tokenised keyword (neither it is a variable, only the IF keyword checks for this particular string), it will display correctly even in CBM BASIC 2.0 editor; on BASIC other than Open ROMs on MEGA65 it will be considered as checking ME variable and (unless ME has non-zero value) the condition will evaluate to false
- switching between modes preserves program in memory, but clears the variables - for MEGA65 native mode I am planning to move the variables from the usual place to MEGA65 extended memory area, clearing the variables is just a preparation
- loading anything below $0800 (read: autostart software) should switch to legacy C64 compatibility mode (but this is currently totally untested)
Last, but not least: THIS IS STILL A PROOF-OF-CONCEPT - MEGA65 native mode memory map might change, BASIC extension described above might change, etc.
Great work! Just an extension, if someone needs "XEMU with VIC-IV support" (not so great term, as the master repo of Xemu also does emulate VIC-IV, just not as well!) and don't want to compile etc by his own, then the usual binary download side has that branch too (the third group of downloadables at the bottom): https://github.lgb.hu/xemu/ (though I am not sure how fresh that stuff is, Hernan should drop be a pull request if it's too old ...)
All sounds great, and looking forward to testing the new high-res text mode.
I also love the IF MEGA65 GOTO hack Beautifully simple.
LG
Paul.
https://vimeo.com/466214042 - this time a small Ultimate 64 feature (but MEGA65 can disable badlines too!)
Very nice !!! Thanks for sharing !