mega65 / mega65-core Goto Github PK
View Code? Open in Web Editor NEWMEGA65 FPGA core
License: Other
MEGA65 FPGA core
License: Other
I'm presently having trouble getting the kernel read from the sd-card and into memory.
There seems to be a chunk of incorrect data in the data, described in this forum post:
https://groups.google.com/d/msg/c65gs-development/q7kCars2Xqw/a_WIWMmcAgAJ
Paul has a few suggestions to chase up that he mentions in that forum thread.
##BREAKS Hypervisor cannot boot computer to C65 BASIC 10 from SD card
Dumping CPs (checkpoints) by KS is a nice way to have some information about hypervisor DOS and KS in general. However, on a real M65 it's a serial port after all, thus there is some delay need to be provided after every characters written out, which is understandable. Currently there is some "busy loop" solution to "burn" enough CPU cycles to provide the needed delay. However for the M65 emulator it's quite uncomfortable since tons of unneeded information will be provided with its own debugging (even at per opcode basis) methods, because of the execution of the delay loop. Also, in the future, some may expect faster CPU implementation for the M65, so it would be better for all, not to depend on "manual timing" but on an implemented "ready bit" by the M65 itself. So, basically the hardware would know if it's ready. On the M65 emulator, I would fake "always ready" as there is no real CPU time needed to be ready there.
after the mega65-fdisk issue, i then get an error during compile of the fdisk programs.
To fix, you need to download "cc65", compile it, and place the binaries in "/usr/local/bin".
I suggest the documentation be updated to reflect this dependency.
I used:
$ cd .. (to get out of the $git_root dir)
$ git clone https://github.com/cc65/cc65.git
$ cd cc65
$ make
$ sudo cp bin/* /usr/local/bin
$ cd ..
$ cd mega65-core
and then the make
continued to execute the XST commands.
The problem is likely to be related to the arrow keys being detected before the RSHIFT key as the keyboard is being scanned.
Paul says look at Kennith's keyboard scanning logic to fix race condition.
to fix:
cd src/mega65-fdisk
git checkout master
someone may want to do the above, and FIX where the submodule points to, and commit that.
It's not something urgent, but just a nice perk to have while debugging.
It'd be nice to be able to type a simple 'reset' command to the monitor and let the hardware reset (and save me from having to swap to the other keyboard and hold restore for a few seconds ;)).
Handy for when debugging startup issues where you want to study/debug and reset over and over again.
Regarding MEGA65/m65dbg#3 and serial speed issues.
Current serial output is inefficient (repeats banner every time, includes spaces, etc).
A more efficient, but less human readable, protocol for use with m65dbg was suggested
which should improve debugging performance.
Is this one better? Is the current one better?
Someone will have to try it to find out.
Sorry if I over-looked something, but by inspecting the VHDL code (to develop Xemu further with better compatibility) I have the suspect (but I can be easily wrong here!), that there is an issue if a hypervisor trap is taken while VIC-III ROM mapping is active, especially for ROM@8000 bit. Since - AFAIK - VIC-III ROM mapping is "stronger" than MAP, mapping the hypervisor memory from $8000 (done during the process entering into hypervisor mode) will be overridden by this ROM mapping, so there is a potential crash after this. Maybe other ROM mapping bits can be problematic for other reasons as well (like passing parameters in memory for hypervisor DOS calls, or whatever). I think, VIC-III register $30 should be saved on entering hypervisor, and ROM mapping bits should be zeroed. On leaving hypervisor, of course, reg $30 should be restored. Probably the same way, as other things (like original MAP state) are saved and restored.
mega65-core/src/vhdl/viciv.vhdl
Line 1689 in c1954d2
is current VHDL can be compiled? I have a lot of issues with signal multi-drivers like on link.
For example the address bus palette_fastio_address gets assigned in lines:
first group, lines: 1689 1693 1697
second group, lines: 2300 2304 2308
First group is combination logic used in read while second group is sequential logic triggered by rising_edge(ioclock) during write. This produces error as this signal has 2 drivers. I didn't use Xilinx development tools. I use Altera. But i've though there is a common HDL rule where signals might be assigned only in one logical block.
There are many such places in the different HDL files.
Finally, i found some modules have different signal assignment than calling module.
Overall code doesn't look like working. Am i right?
It seems to change between bitstream builds, suggesting something subtle is going on, but keyboard scanning at 40MHz is sometimes quite broken.
Probably best to write a matrix scanning tester to try to figure out exactly what is going on.
io_settle_delay in gs4502 should be freezing the CPU for more than long enough for the keyboard matrix to stabilise.
i have experienced now several times, that, when leaving the Freezemenu by pressing "F3"
for certain programs the SID is not working anymore.
The rest of the game works, but no more audio output.
my setup:
Nexys4DDR with widgetboard.
Video: PAL
tested on:
International Soccer
Last Ninja 1
Spy vs Spy 1
At least for me, if there is no MEGA65.D81
on the SD card, KS causes to "out of hypervisor memory" execution. As far as I can tell this caused a BCC op in kickstart.a65
, line 649 which would branch to label nod81
if no file found. However since this is the main execution "flow" of booting with empty stack, and nod81 is a routine having RTS on the end, it seems this was, what caused the stack "underflow" and execution at an insane address popped from the stack by RTS.
Though I am not really sure about the kickstart structure yet, I think, BCC
mentioned above should be modified to branch to d81attachfail
instead of nod81
. I've tested that modification of mine, and it seems KS booted normally with M65 emulator, using my "faulty" FAT32 card image, with no MEGA65.D81 (but ROM is OK for sure). It was tested with the EOC/dirent-end patches combined, and it seems with this fix as well, everything seems to be normal.
difficulty in knowing how to add a component to the design
using the ISEv14.7 as a glorified text-editor, I have changed iomapper to include a new-component that I built myself. After saving the project etc, the new-component appears under/within the iomapper.
Yes ISE can build the design to include my new-component.
BUT, when building the design using "make bin/lcd4ddr.bit" the build process fails because it cannot find the vhdl-file for the new-component.
it seems i need to go into the Makefile and specify the path to the vhdl-file of the new-component.
Currently I am unsure where to modify the Makefile to include my new-component.
Yes I understand that PGS wants the compile/build to be performed via the command line, specifically using his Makefile (and run_ise), and this is the authoritive method of compilation, BUT that system does not easilly allow a new user to come along and add their new-component to the design, without having knowledge of the build system.
Most/all new fpga/vhdl people to the team will be familiar with ISE, so I suggest that the Makefile/run_ise process looks to the ISE-project-file for what files to load to be able to synthesize.
Just an idea, what do you think?
Typically if there is a bug in the hypervisor, it will end up running code outside of its $8000-$BFFF 16KB memory. It would be helpful to have an option to trap when this occurs unexpectedly, so that hypervisor bugs can be tracked down more easily.
There can be cases when hypervisor DOS gets wrong about reading (or writing) from insane position, including:
In any of the cases, it would be nice, to have some kind of "hypervisor DOS panic" (maybe with some debug info?) on the screen (even if it's not M65's fault, that the file system is bad). Currently, as far as I can see with my M65 emulator tries (Xemu), in case of invalid operation offset, hypervisor just gets back an error, and it re-tries again and again, and the user has no idea what happening in the background. I have the problem with Xemu, that with my (otherwise seems to be valid) FAT32 file system caused DOS tried to read something well beyond the total size of the SD card actually, and it stuck in a loop to try again and again. In Xemu, I could handle that with doing offset check for the whole emulated card image and panic'ing by Xemu itself, but it should be nice to have some kind of similar feature built-in.
I think, it would be nice, to create a table (if not done already) of used partitions, about the "offset range" which is valid for the given partition. On each read/write ops, it should be checked that the requested offset is in the range. If it's not, there can be that "panic" stuff.
Hello,
I tried a partial rewrite of the etherload stub to get arp replies working. I succeeded, almost. Even though the code should reply always the same if arping'ed from the same host, the results vary.
Without knowing what happening inside the hardware, I can't go on any further.
Once this issue has been solved, I might be able to squeeze in support for ICMP, so the stub will reply to pings.
etherload.txt
unsure if this is a problem others are facing, but,..
after running:
sudo src/tools/monitor_load -l /dev/ttyUSB1 -b bin/nexys4ddr.bit -k bin/KICKUP.M65 -R MEGA65.ROM -C CHARROM.M65 -4 src/utilities/test01prg.prg
the serial port seem unusable.
refer to post:
https://groups.google.com/d/msg/c65gs-development/Pmz0s4NfCdk/p7gI-UyGBAAJ
Upon closing the program, should the serial port be reverted back to its previous state as when the monitor_load program started?
This one relates to #2 somewhat. Paul suggested the creation of a serial buffer for the comms sent out of the hardware by the monitor:
https://groups.google.com/d/msg/c65gs-development/FESl92s4vEM/rpmUe5Z4AQAJ
Perhaps this might improve performance too?
The "px100mhz" branch contains "./Makefile" and "./src/Makefile".
One of these seems the parent of the other.
Need to remove duplication and resolve what-rules-go-in-which-Makefile.
Backspace is broken in C65 basic, probably have to increase the delay after messing with the keyboard scanning at 50MHz.
Testing the latest Bitstream and the soft Reset implementation
i thought about the main approach of doing a Reset on the Mega65.
How is it about, of making it possible, to swap inside the Freeze menu, between a soft reset and a Reset, without module check.
So a kind of a Hard Reset, maybe toggle between the two by pressing "R" and swap the "F5" key description accordingly between (F5 - (S)-Reset) and (F5 - (H)-Reset)
This would result, that the user would have the possibility of 3 different Reset functions , excluding Powering Off/On the Mega65:
1 x Soft reset (like shortening pin 1 and 3 on the c64 userport or typing SYS64738)
- via Freeze Menu (S)-Reset
1 x Hard Reset (excluding the module check)
- via Freeze Menu (H)-Reset
1 x ultra Hard Reset/Reboot
- via Reset button on the Mega65
i want the checkpoint messages modified so that:
missing are
src/vhdl/colourram.vhdl
src/vhdl/shadowram.vhdl
As per this discussion in the c65gs forum:
https://groups.google.com/forum/m/#!topic/c65gs-development/frjfpoLNE_I
When in GO64 mode, the CPU is unlocked and at 1MHz, but when we run SYS 49152 to use the disk mounter, the CPU speed is set to 48MHz and locked.
This is causing games/apps that are loaded after exiting from the disk-mounter app to run at super-fast speed.
While in matrix mode, if you stop the CPU, trigger the leave matrix mode hypervisor trap and then single step through until you leave matrix mode, you can no longer resume the CPU without a serial input.
This is because the CPU is paused and thus the hypervisor can no longer trigger matrix mode.
The user can not resume the CPU from user mode.
Please use https referencing to github submodules:
[submodule "src/mega65-fdisk"]
path = src/mega65-fdisk
url = https://github.com/MEGA65/mega65-fdisk.git
+[submodule "cc65"]
we want the design to support targeting both types of Nexys4 development boards, namely the
This will allow those people who have the non-DDR board to be able to create a bitstream targeting their board.
Probably something exists already like this? What I mean: a hypervisor DOS call, to read and write SD blocks, with all the works done, ie converting block level address to byte offset if not SDHC, doing the reset, in case of an error during the operation, etc. So: a "bullet-proof" block read/write implementation. I think, it's OK to leave to the caller to fill the SD sector buffer or copy its content (in case of read), just the operation itself, with input value of the sector number (always block level addressing even in case of non-SDHC case, when it's converted by HDOS), and output as the status (error/OK), the block data itself can be transferred in the usual place without copy, ie te SD sector buffer itself. According to my tests in my "ethernet-monitor" solution, it's not so much trivial at all, especially in case of write. Also, M65's fdisk utility can benefit from this, so it don't need to implement the algorithm to write/read block just using these calls. Moreover: it would be also nice, if kickstart would do the size test on boot, and any program just query the pre-stored value from the only test time at boot. Again, it can be useful for the fdisk utility too, and for other low-level access software as well, including my project, of course.
Surely, it's just my idea, that it can be a useful function. Since HDOS can read blocks from SDHC/non-SDHC too, and now write too (if I am right), it should have the corresponding routines to do that, so the task is only to provide these functions via hypervisor trap calls as well for the "user space".
usermanual was sourced from
https://docs.google.com/document/d/1fmEUg6hDdWRb2tFZ3n4LG7S1mNP04_SUAW5DrE8zRpk/edit and now will be maintained at "/doc/usermanual0.md".
To do includes:
in "px100mhz" branch, the target "bin/nexys4.bit" does not build, error is below.
==> 20180210_16:10:30 Starting: xst, see isework/nexys4.syr
xst -intstyle ise -ifn isework/nexys4.xst -ofn isework/nexys4.syr
Makefile:450: recipe for target 'isework/nexys4.ngc' failed
make: *** [isework/nexys4.ngc] Error 6
change vhdl to reduce the number of WARNINGS, ie
Please consider to adding automatic Ethernet tag removal on RX, so user don't need to deal various network setups where VLANs are configured or other. Without this, every network aware program on M65 using its ethernet capability needs deep knowledge on very different technical details what can be on an average ethernet LAN. Also, to making things symmetrical (stripping tags on RX, adding tags on TX, the user always do not need to mess with those tags neither by inspecting the RX buffer, or on filling the TX buffer), it would be very nice to have automatic tagging on TX as well, however I am not sure what information needs to be set up for M65 and how, that he know what it should add then. As far as I know, there can be odd situations where double tagging is used, though I am not so sure, how generic and realistic scenario it is.
in kickstart_dos, PGS has previously experienced:
; XXX - 16 bit BNE should be fine here! Why doesn't it work?
; bne partitionerror
beq ddop11ok
jmp partitionerror
ddop11ok:
Now I have experienced this too.
lda [sd_sectorbuffer+$1FF]
cmp #$AA
bne partitionerror
fails because function "partitionerror" seems out of bounds.
SO: Why doesnt this instruction get converted properly by Ophis to the 16-bit branch like other detected branches?
Hi Paul,
i have the m65pcb-ports branch,
Compile breaks because the sdcard-files toplevel subdirectory does not exist.
it should be created if it does not exist.
The error occurs when cbmconvert tries to build the D81-file from existing PRGs.
Makefile:217: =============================================================
Makefile:217: ~~~~~~~~~~~~~~~~> Making: sdcard-files/MEGA65.D81
cbmconvert -v2 -D8o sdcard-files/MEGA65.D81 src/utilities/ethertest.prg src/utilities/etherload.prg src/utilities/test01prg.prg src/utilities/c65test02prg.prg src/utilities/c65-rom-910111-fastload-patch.prg d81-files/* src/utilities/diskmenu.prg
`src/utilities/ethertest.prg':
`ethertest,prg':
Wrote 147 bytes to image "sdcard-files/MEGA65.D81"
Archive extracted.
<snip>
`src/utilities/diskmenu.prg':
`diskmenu,prg':
Wrote 1781 bytes to image "sdcard-files/MEGA65.D81"
Archive extracted.
Unexpected error while writing image "sdcard-files/MEGA65.D81"!
Makefile:217: recipe for target 'sdcard-files/MEGA65.D81' failed
make: *** [sdcard-files/MEGA65.D81] Error 4
This seems to be a problem with sd.vhdl. There is a derivative of that code that we should consider replacing it with:
https://github.com/xesscorp/VHDL_Lib/blob/master/SDCard.vhd
That code has a process where it redoes the first command, until it succeeds without an error.
We should try implementing this, or probably more easily, just switch to using this newer version.
Paul.
There seem to be two problems here:
When an SD card cannot be read for some reason, it usually shows up as a "00 partitions mounted", instead of saying something like "cannot read master boot record", which would be more informative.
currently a hook/handler has been implemented to:
It is expected that the functionality at (*) be developed to:
PGS has advised that the "BOULDERMARK" program no longer works on the current bitstream.
The Bouldermark program runs a special-level in the Boulderdash program and counts how many frames it takes to complete.
The Bouldermark program can be found on the MEGA65 image.
unsure if this is related to the SDcard reading, or the ASM display routine, or the generation of the file itself with pngprepare.
refer to thread:
https://groups.google.com/forum/#!topic/c65gs-development/wuaiaAA0G9c
Add "m" command to serial monitor to allow setting mouse position and button status, and enable/disable this mouse emulation mode.
In my "wannabe CP/M emulator" for M65 I discovered the issue, that sprites' horizontal coordinate is not there where it should be. I can be wrong, but AFAIK, sprite position etc should be independent of the used video mode. So I used the same theory to calculate the X coordinate as it would be on C64 (or so ...) but the sprite then is far too be right compared to where it should be. You can see the issue in this video (around 0:35), the "cursor" I use there is a sprite for real, and I calculate its position from the text coordinates:
I think it would be nice if each SID would not be fixed to a "left" or "right" channel, but have an additional register (maybe $D43F, $D47F, ...) that would pinpoint the "position" of the audio like a crossfader (-128/-127 as left channel, 127 as right channel and 0 for both channels, other values interpolate).
seems when a byte is RXed, the FIFO should change status from EMPTY to HASDATA.
seems you need to POP at least once for the expected bahaviour(as above) appears.
Somewhat complex topic ....
There is a C65-M65 incompatibility issue that is, the last 2K of chip-RAM is the first 2K of colour RAM. On C65 this area can be used for VIC-III to fetch graphics data (eg bitplane) too if some doesn't need the colour RAM functionality. AFAIK it wouldn't work with M65. I would suggest to use 128K chip RAM (and not 126) by VIC-IV anyway on M65. The last 2K would be "overlapped" by the colour RAM 2K though, CPU would see that all the time, however VIC-IV for non-colour fetch purposes would always see the chip RAM there too. Thus, only the policy is needed that writing that area would affect both of colour RAM and chip RAM at the same time. That would solve this compatibility problem, as - I guess - for timing issues it wouldn't too much possible other way.
For some purposes, it's kinda uncomfortable to always have the CPU port at phys addr 0/1 and the colour RAM at the end of 128K. What I would love, is to map 256K RAM (chip+fast) without the overlapping colour RAM 2K + I/O port at another, higher physical address, so it would be possible for M65-aware programs to MAP it, linear-opcode-addressing it, or DMAing it if needed. It's only really useful though, if chip the colour RAM and the CPU port is not there. This also means, that care must be taken: if some write the last 2K of chip RAM at this higher mapping address, there would be a difference between colour RAM and chip RAM "write through" policy (see point 1) so it should be handled with care. But it's an M65 feature, so only M65-aware things could do that for real. I would vote not to take account (but surely it doesn't need to be this way) "ROM protect" for fast RAM here at least only for the "normal" position ie the second 128K of physical address space of M65.
I would really love to see another mapping too, not instead but also. That is, the four 64K areas of chip + fast RAM would be mapped for twice for each 64Ks. It can be useful especially when it's needed to "simulate" 64K address space wrapping around behaviour used with linear addressing mode, especially my strange ideas to emulate 8080/Z80 from software, where it's an issue currently too (surely it can be handled by software but much slower then).
I'm really not sure how this can be done ... I saw things like "virtual pages" in the IOmap.txt, but I have no idea what it means. Anyway, for many purposes I would also love to use a possibility for having a 64K somewhere in the higher physical memory area (and again, if possible, duplicated, so a next 64K with the same content too, for the reason see my point 3.) Maybe this should be done differently, but my idea, to have four 16K areas allow to see any of the 16K slices of fast+chip RAM there (16K aligned seems to be enough) with also the possibility to make any of the 416K mapped as read-only or not at there at least. It would solve many problems, like emulation of other machines but even for porting software and OSes to the M65, as many of them require something like this possibility. It even includes the easier porting of some C64DTV apps (surely it won't happen magically, it's only a minor similarity then!!!!), but even Z80 based GUI-aware, multitasking and micro kernel message passing architecured SymbOS, where M65 is fast enough to actually emulate a Z80 for it, but this Z80 emulation does not allow too much this 416K or any similar memory paging it needs. it also true for emulating many other 8 bit machines by software, btw.
According to https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system
The FAT table contains last cluster for chain ("EOC") as values 0x?FFFFFF8 - 0x?FFFFFFF. It seems, KS only recognizes 0x?FFFFFFF, though as a test, I can see, that Linux dosfstools uses 0x?FFFFFF8 (this behaviour and compatibility problems even mentioned by the page). This can be an explanation why file systems created on some OSes doesn't work for us. The page also mentions about the fact, that FAT32 is actually FAT28, and the high 4 bits are not so much used to express cluster number but not always zero still, that's the reason of '?' marks in the hex numbers above (so they should be "masked out" before using a value as cluster?). It seems it's even recommended to treat any value in FAT which is over the max number of cluster on the given FS as "EOC", not only the range above, for better compatibility (as the page claims: "a good implementation ..."). This is exactly the problem I noticed with my M65 emulator with my own created FAT32: soon, invalid block is tried to be read on directory scanning, it can be the issue, that EOC (what is produced by my Linux box, but what is accepted by my various "stuffs" like digital camera etc) is misinterpreted by KS, and tried to be converted into SD block number the read -> thus the problem we see. As far as I know some other people also has problem like this.
I think, "sensing" EOC should be modified to care about these information too, including the 4 high bits issue, the multiple possibilities for EOC, and maybe even that any cluster number in FAT should be treated as EOC, if it would cause to address a cluster which does not exist on the used FS. This should be true for directory parsing, but also, for any file, where FAT is used for anything to detect EOC situation. Also maybe not only EOC, but cluster info from FAT should be handled to use only the lower 28 bits just in case for some "strange" FAT32 file systems, and even better compatibility.
I found this table especially useful (it mentions even more EOC possibilities, like cluster 0 and 1 ...):
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Cluster_values
The other issue is more like a performance gain than a real issue: again, according to the page above, during a directory read, if the 32 bytes directory entry starts with byte 0, directory parsing can be stopped. So even there is no need to parse the rest of the cluster (or read the next logical sector belonging to the actual cluster ...), and maybe no need to even check for next cluster then in FAT. It seems, this can be a compatibility issue in general in case of older FATs (FAT12 and FAT16) with some extreme old DOS versions, like DOS 1 and DOS 2 and some half-CP/M-half-DOS beings. However, as FAT32 is surely not handled/produced by these, I think, we can surely say, this theory is true for our case with FAT32-only KS. Even deleted files has first byte as 0xE5, zero should only encountered if no other entries follows in the directory (let it be the root directory or any other - as with FAT32 there is no difference, unlike with FAT12/16). Reference:
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.