MEGA65: adopt more decent hyppo #140
Comments
|
Reason why I may want to delay adopting a new Hyppo at least this 'early'. |
|
A more fresh experiment, still the BRK problem: After this on the screen (no cursor, or ability to type):
Also before this: and (many similar): |
|
Ok, what I've learnt today from Paul: On Discord: https://discord.com/channels/719326990221574164/781481205639020554/917518905285685368 there are bunch of memory regions must be pre-filled with the right content (filled with the bitstream on MEGA65), only open-rom is not enough. The reason of the BRK, that hyppo tries to execute the flash menu, but it was not loaded, so only zero bytes there, thus the BRK problem occurs. Also, the check of hypervisor running outside of hypervisor RAM is largely outdated, as for now hickup does this by will, though maybe only the "boot" process, and after the first return from the first hypervisor call. it's still valid to have the check. I may open a new branch to play with newer hyppo, as it seems it requires "some" re-work here and there, it won't be as easy to replace the hyppo image only. The new branch for the experiment: hyppo Important "map file" for hyppo for debugging: Recommended mega65-core branch to get files from: Needed pre-initialized memory areas (according to That it seems:
NOTE: other files should be put on the emulated sd-card as well, as those may be loaded (once working freezer is a reality in Xemu) like sprite editor and things like that. TODO: get full list of needed files, let it be either memory-initialization purposes, or other. |
|
Initial work committed to branch First, there is QSPI-flash issues, which is expected (this must be handled somehow, as the error is not fatal, but it's really annoying that emulator users always must to press the famous ANY key to continue, though doing so really allow to continue without any noticeable ill-effect):
Second, there is an SD-card detection problem though:
STATUSThis part is moved TO THE TOP of this page, since it was already confusing enough ... |
|
DONE, a minimal built-in program to Xemu is added to function as a "fake" version of the flash utility. |
|
ONBOARD.M65 does an FPGA reconfiguration trigger by writing $42 to $D6CF. I've just implemented this by a reset. Now it does not stuck after save settings. However I'm still unsure, if it's a good idea to leave this tool in an emulator, or not ... I may replace it with a "stub" like with the flashing utility. However it would mean, Xemu's solution to write some config out as its own must be updated, since there is such a code, but I guess it's not valid anymore, that's the reason ONBOARD kicks in. |
|
Added memory pre-init for reset routine to allow to access utility menu from emulation menu. Now the menu is displayed, however configure utility cannot be entered, only a white screen is shown. This worked before with older hyppo. The same for format/fdisk and keyboard test utilities :( I also see some BRK stuff here, after enabling in-deep debugging in Xemu to see what's happening. |
The problem: I've triggered matrix mode with keypress by emitting a hypervisor trap for that functionality. Which works fine, unless you're already in hypervisor mode (boot process, trying to debug situation when stuck there!). In hypervisor mode, surely it's not possible to cause a trap. Thus my idea, is to control matrix mode directly bypassing the trap part. Seems to work fine so far ...
As part of #140 I encountered the problem, that xemu_open_file()'s method to do a "second mode set" open (if first failed) has a serious design flaw: it sets the pointed value to zero if the first (default) mode was used, however RD_ONLY is also gives zero ... Thus I introduced the XEMU_OPEN_FILE_FIRST_MODE_USED constant (set to -1, thus it's very unlikely it's a valid "mode" value! - ie all bits are one) instead of zeroing. Some places of Xemu had to be modified to use the new scheme though.
Note, that D64/D71 is mounted as D81, so the software (like ROM) need to translate disk geometry. The problem with this commit: * D65 support has its own geometry unlike D64/D71, but I am not sure what it should be! * Currently only external mount works for any non-D81 format. The previous "fake D64" method has been deactivated.
Also introducing (not a complete list): * (acme) REP file based hypervisor debugging * HDOS call tracking * HDOS virtualization alpha stage * System initialization changes * Better initial D81 mount tracking * More sane CLI/options (eg single rom option to load ROM, no need extra -forcerom and other bizarre things)
* Reogranization some of the UI menu * Provide new functionalities
The heart of the `hyppo` branch, that is using a new and decent enough hyppo. Also it required many changed here and there to support the new scheme, like using an initial ROM (open-ROMs) pre-filled the memory along with other utilities.
|
Branch hyppo is now merged into next (the previous next into master). Though it's not perfect, it's finally mature enough to be at least "usage material" for wider audience keeping mind, that it can still buggy. |
|
I close this issue now, since the main goal is achieved to have a usable emulation running a decent enough hyppo, and already has been a very bumpy and long road. Individual remaining and known bugs (and possible unknowns ...) should be addressed as-is after this. |
Project status:
Highest priority for now
So there should be some SD-controller emulation problem, that hickup thinks now, it's not an SDHC card. Though Xemu only emulates SDHC card. As hyppo seems to detect SDHC by trying non-sector aligned access (as with non-SDHC cards the addressing is byte based, but must be sector aligned, thus a method to detect it), but it should work anyway. So I assume, there is some generic problem with SD-controller emulation that a regular SD-sector read command fail, when it shouldn't.Jimbo on MEGA65/Xemu discord suggested a two line hack for keeping status read busy when external bus is selected for SD operation. This seems did the trick, however the whole SD-controller emulation is very messy ...
TODO list:
Avoid the QSPI problem somehow ...Fix the hypervisor-execution check error message, which always kicks-in nowUtility menu cannot be accessed any-more, (emulated) MEGA65 says, you must power-cycle ..."Boarding utility" kicks in and freezes with green screen after saving, though after a restart, system seems to work fine!Remove some old crap (like C000-utils?)Remove-fonrefreshoption and make it compulsory part of the code if custom ROM is used.Is CHARROM file needed at all on the SD-card?Alter code to allow to specify custom system files, simplify/cleanup code.Look after the problem that the bottom of the screen is missing (though it seems only in NTSC mode ...) UPDATE: this may be a real issue, however hard to reproduce, and according to others, sometimes similar symptoms (not sure, if they're the same though) can be seen on the hardware as well. So let's not deal with this, at least for now.Remove, or alter hickup debug code, which would still expect Ophis-specific files, so quite useless now. Probably it won't hurt if remains, but would be not very hard to use acme's symbol file as well (since hyppo went away from using Ophis to Acme as the assembler!)Probably rename everything "kick" to "hick" in Xemu (also options)Update sd-card updater code to populate with new system filesRevise, how "chrwom" data is extracted from VHDL, a binary file would be much nicerRevise all the tricks/hacks of the "first time hypervisor leave" hookRevise/fix/cleanup how ROM is loaded, ie user controllable custom ROM, and do not collide with the pre-init openromMaybe allow Xemu to boot into open-rom built-in just for fun (not so high priority)Maybe add an UI option to temporary reset with an external ROM without the need to update SD-cardAdd hypervisor version reportAdd HDOS hooks so Xemu can check and/or override HDOS trapsDEBUGPRINTinstead ofDEBUG) and set specific stuffs (likeDEBUGHDOSback to alias forDEBUGrather thanDEBUGPRINT). Especially insdcard.candhdos.c, but maybe others, in general!vic4citself does too muchDEBUGPRINTas well, however it's not the scope of this issue too muchRestore the logic of "default D81 is outside of the SD-card" functionality. Maybe check if MEGA65.D81 is on the SD-card's root dir, record its starting SD sector number and use external source if internal mount finds matching mount sector with that. So it would be "kinda transparent".Remove the ugly "Xemu information query" method done in the I/O decoder ... I guess nobody used it too much (other than my info utility ...) and it's now preferred to use the Xemu specific trap to get emulation related information (also much cleaner, and much easier to implement and also to use!)Consider supporting D64 with on-line translation to D81, maybe in R/O mode only though! External mount only, since there is no real hardware equivalent of this on MEGA65 to support via registers! (possible IEC drive emulation in future in Xemu is a totally different topic!)Support for D64 and D71 images, mounted as D81 (as per geometry) surely with checking the image size violations. The actual geometry conversion is need to be done in software (ie, by ROM, for example)Go for the MEGA65-release stage of hyppo and system files! Now I usehwscwhich is maybe buggy and would be better to match with real MEGA65 expected to be shipped with, rather than some other branch! So themasterbranch.Matrix-mode control in Xemu (key trigger) should not use a hypervisor trap as it would make it impossible to toggle matrix mode when in hypervisor mode. Surely, in Xemu UI it's still possible, but let's make the life easier and more consistent.normalize UI menu a bit for D81 mounts, too many options, maybe divide the new disk menu (also contains sd-card submenu) for drive8 and 9 and have the options there, specifically at least "mount + use", "create + use", "detach", also maybe an option for mounting default for drive8 (but then it should matter if D81 from SD-card is enabled or not!)The text was updated successfully, but these errors were encountered: