There seem to be two problems here:

1. C65 ROM gets stuck waiting for busy flag
2. The sector gets written with the data rotated by 2 bytes.

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"]

• path = cc65
• url = [email protected]:cc65/cc65.git

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.

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.

currently a hook/handler has been implemented to:

• detect when a double-tap restore-key is made
• enter HYP-mode
• change border color (*)
• leave HYP-mode

It is expected that the functionality at (*) be developed to:

• display a menu on the screen
• provide HYP-mode functionality
• allow clean exit from HYP-mode

The problem

There can be cases when hypervisor DOS gets wrong about reading (or writing) from insane position, including:

• bug in the hypervisor DOS itself
• the file system is corrupted / contains errors what user uses
• the file system is valid FAT32, though hypervisor DOS can't use properly (expects different FS parameters, whatever)
• user program itself tries to read (or write) directly at block (not FS) level, where the given position is invalid

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.

Possible solution

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.

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

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?

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

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.

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

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.

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".

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.

• the previous build system (using compile.sh) made use of the ISE-project-file to know what source files are required to synthesise the design.
• the new Makefile process requires you to not only add your component (and modify parent-component.vhdl) in ISE, but also in the Makefile somewhere.

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?

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.

missing are
src/vhdl/colourram.vhdl
src/vhdl/shadowram.vhdl

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.

Add "m" command to serial monitor to allow setting mouse position and button status, and enable/disable this mouse emulation mode.

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

Somewhat complex topic ....

1. 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.

2. 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.

3. 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).

4. 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.

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.

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

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.

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.

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.

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.

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.

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.

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:

https://www.youtube.com/watch?v=iJwvp6lZ2DU

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).

Is this one better? Is the current one better?
Someone will have to try it to find out.

m6581_voice.zip

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.

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?

change vhdl to reduce the number of WARNINGS, ie

• better use/routing of clock/reset lines
• initialisation of registers
• remove unused signals/ports
• etc

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?

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.

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.

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:

1. add CR/LF, formatting etc
2. make it appear as close as possible to the original docs.google file.

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.

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

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.

Backspace is broken in C65 basic, probably have to increase the delay after messing with the keyboard scanning at 50MHz.

we want the design to support targeting both types of Nexys4 development boards, namely the

• Nexys4DDR (currently is supported), and
• Nexys4 (is no longer supported, and it should be).

This will allow those people who have the non-DDR board to be able to create a bitstream targeting their board.

i want the checkpoint messages modified so that:

• they are shorter
• they primarily display the checkpoint TEXT payload
• checkpoint text payload increased in number of chars it supports.

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?

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

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