Trying to compile, get errors

[Daniel England]

Heyas!

I did this ages ago and was successful but I want to be sure I'm up to date so I'm starting from scratch.

I followed the instructions but have failed to compile the bitstream.

It seems that several directories are not being cloned/checked-out from GitHub when I do the pull.

I've gotten several errors.  I'm trying the m65pcb-ports branch.  Actually, now I think of it.  That's wrong because I'm using the Nexys4DDR board.  Can someone tell me which is the latest branch for the Nexys4DDR?

However, I'll continue.  Firstly, the documentation is incorrect.  You need to "make bin/nexys4ddr.mcs" not "make bin/nexys4.ddr".

But...  I still got errors.  I had to create the directories <m65core>/bin and <m65core>/sdcard-files for the make to progress.

But then, it fails on making mega65-fdisk because the directory is missing!

I've looked at the repository and the icon for the fdisk directory is weird...

I don't want to copy the files manually.

How do I resolve this?

Daniel.

[Daniel England]

Hmm...

On further investigation, looking at the px100mhz branch (which GitHub suggests is the most recent branch) from the web interface to GitHub, trying to browse into the src/mega65-fdisk directory I get a 404 error!  I don't get that error from the m65pcb-ports branch.

Daniel.

[Paul Gardner-Stephen]

mkdir bin

git submodule init

git submodule update

will check out the fdisk source.

then:

make bin/nexys4ddr.bit bin/nexys4.bit bin/mega65r1.bit

(leave only the targets you need) to build bitstreams.

We will be cleaning up branches as soon as we confirm that we are happy for px100mhz to become master.

Paul.

--
You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel England]

Paul,

Hmm..  Sorry I checked the "issues" in GitHub and found the solution that Ben used.

However, I still had to create symbolic links for cc65 and cl65 in /usr/local/bin because they are installed into /usr/bin

Also...  There seems to be some kind of issue with my version of ISE.  For some reason the settings don't set the path correctly.  I will investigate that at some other time but for now, I'm just altering the path manually.

Additionally, I had to change the source code for one ascii.h to remove the mapping for character $00 because it said that remapping it is not allowed.  Is this a problem with my version of cc65?  Should I try to compile it from source?

And...  Its nexys4ddr.mcs not nexys4ddr.bin that you have to make since there is no rule for nexys4ddr.bin.  Is there some kind of issue with this??

Daniel.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

[Daniel England]

Paul didn't seem to reply here so I'll just quickly mention that he said he meant "nexys4ddr.bit" not .bin.

[Gurce Isikyildiz]

I'm trying to get up-to-speed on re-building the latest bitstream this weekend.

I bumped into similar hurdles to Daniel, so thanks for the info shared in this thread. I'll just jot down a few more hurdles I faced, in-case others bump into them:

PROBLEM:

/usr/bin/convert -colors 128 -depth 8 +dither assets/mega65_320x64.png bin/mega65_320x64_128colour.png
make: /usr/bin/convert: Command not found

SOLUTION:

Install the ImageMagick package on your linux/cygwin system.

-----

PROBLEM:

/usr/local/bin/cc65 -t c64 -O -Or -Oi -Os --cpu 65c02 -o fdisk.s fdisk.c
make[1]: /usr/local/bin/cc65: Command not found

SOLUTION:

Grab the cc65 source, compile and install it via the steps here:

• git clone https://github.com/cc65/cc65.git
• cd cc65
• make avail

[Gurce Isikyildiz]

Got this error midway through the building of the bit-stream (I did a "make bin/nexys4ddr.bit"):

Check ./build-logs/compile-<target>-<git commit>-X*.log for the log files, X={1,
2,3,4,5,6}

msg_gitcommit: .byte "GIT: px100m,2421533+DIRTY,20180121.09",0
/home/vets/mega65-core-gurce

==> 20180121_11:36:58 Starting: par, see isework/nexys4ddr.par
rm: cannot remove './isework/nexys4ddr_map.ncd': No such file or directory
make: *** [Makefile:451: isework/nexys4ddr.ncd] Error 1
rm isework/nexys4ddr.ngc isework/nexys4ddr.mapncd

I had a look at the "run_ise" script, is it due to the script's "par" assuming that this *.ncd file would exist? I noticed that "run_ise" was run several times in a row (xst, ngdbuild, map then par), so I looked at the "map" step prior to "par" (which seems to be responsible for generating this _map.ncd file), and I didn't see any errors reported during the map step (no errors mentioned in the "build_logs/*_3-map.log" file, and none mentioned in "isework/nexys4ddr_map.mrp" either).

Any ideas?

[Gurce Isikyildiz]

I studied the "run_ise" script a little further, there may be a problem with the logic in there. Here's what I'm seeing:

• run_ise map runs first:
  • The map command generates the "isework/*_map.ncd" file
  • It then renames the file to "isework/*.mapncd"
• run_ise par runs next:
  • It tries to remove the "isework/*_map.ncd" file and fails because it was renamed in the last step of "run_ise map"
  • It then tries to make a symbolic link from the renamed "*.mapncd" back to the original "isework/*_map.ncd" name
    - Oddly, the "*.mapncd" lacked the "isework/" sub-folder prepending it though, so I wonder how this could possibly work...

I'll ponder this some more and try tweak this script in some way to prevent this... (once I figure out what's meant to be happening here :))

[Gurce Isikyildiz]

Ah ok, I think the penny is dropping on what is trying to be accomplished here. That symbolic link step turned out to be fine (just my own misunderstanding), but the step of removing the non-existent seems to be the sole culprit here.

I believe it might be trying to remove any pre-existing symbolic link? If so, I'll just add an "-f" to the rm command to ignore any non-existent files:

if [ $TASK == par ]; then
    #
    # ISE: place and route
    #
    echo "==> $datetime Starting: par, see ${TARGET}.par"
    rm -f ./isework/${TARGETNAME}_map.ncd
    ln -s ${TARGETNAME}.mapncd  ./isework/${TARGETNAME}_map.ncd
    par ${ISE_COMMON_OPTS} ${ISE_PAR_OPTS} ./isework/${TARGETNAME}_map.ncd ./isework/${TARGETNAME}.ncd ./isework/${TARGETNAME}.pcf > $outfile4
    exit $?
fi

[Gurce Isikyildiz]

Well, adding the "-f" let it progress further, but I bumped into some other weird issue:

Constraints file: ./isework/nexys4ddr.pcf.
ERROR: Pds exception in PahDesignLoader:
EXCEPTION:Pds:Pds_PahDesignLoader.c:153:1.4 - Corrupt Database.
FATAL_ERROR:Par:baspwpar.c:3938:1.467 - Par has discovered an exceptional condition while trying to load the design
   ./isework/nexys4ddr_map.ncd - from which it cannot recover   For technical support on this issue, please visit
   http://www.xilinx.com/support.

Hmm, maybe something got corrupted on the way, so I've done a make clean and restarted synthesis on my winxp virtualbox.

Since synthesis on it has proven very slow (about 3 hours from my last memory), I've tried vpn'ing into a faster office computer (running Ubuntu) and tried to trigger a build there.

I noticed that it didn't need the "-f" flag for the rm step. While it still complains that this file does not exist, that in itself does not cause that version of make to come to a complete halt (it progresses through it).

On 22 January 2018 at 00:19, Paul Gardner-Stephen <pa...@servalproject.org> wrote:

Sounds plausible. Try that, and if it works, I'll make the change to the file.

Paul.

--

You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.

[Daniel England]

You're up late! :)

Are you doing the synthesis on WinXP??  Using Cygwin perhaps?  I'm not sure that any of us are trying that.  I think we're all doing it on Linux.  Perhaps this is why none of us have gotten that problem as yet?

Why would you be using WinXP?

Daniel.

[Gurce Isikyildiz]

Whew, finally got a bitstream built on the Ubuntu work pc, took 1 hour and 10 minutes, that's a big improvement on what I'm used to.

I'll leave the WinXP/Cygwin vbox build on overnight and see how that fares in the morning... (That's the one with the extra "-f" flag added)

[Paul Gardner-Stephen]

Building on windows is likely to have all sorts of problems.

Paul.

[Gurce Isikyildiz]

Thought I'd give the bitstream I built in Ubuntu a try, seems to work ok'ish. Just a few things:

• the screen contents are drawn a bit to the right
  (I remember you mentioned a way to tweak this via registers, I'll try hunt down your advice on that)
• I did GO64 followed by SYS 49152, but I didn't see the disk chooser menu. It just seems to freeze

Here's a screenshot of the bootup text, in-case there's a hint in there of where I've gone wrong:

[Daniel England]

Heya!  Nice to see you got it working.

Yes, the screen is a bit to the right for me, too.  I adjusted it on my monitor.

The DiskMenu isn't there in RAM anymore as I recall.  You have to use monitor_load to push it up (probably the diskmenu.prg/diskmenuprg.prg program, instead) or you can get it from the MEGA65 disk image off the top of my head.

Paul is setting up a new way of getting into the utilities.  There will be an FDISK utility, a CONFIG utility and the DiskMenu (but that will be from the "freeze" menus, he says).

I'm working on the CONFIG utility right now.  Its almost ready.  I've had a few delays.

Daniel.

[Paul Gardner-Stephen]

Yes,to get the SYS49152 disk chooser for now, you need to copy it onto the SD card as C000UTIL.BIN, which kickstart will load on each reset.

As Daniel says, I am actively working on freezing and unfreezing, so that we can instead have the disk chooser as part of an (eventually) sophisticated freeze menu, that will allow switching mounted disks, swapping tasks and other things.

Paul.

--

[Gurce Isikyildiz]

Thanks guys for getting me up to speed on this topic :-)

[Paul Gardner-Stephen]

You're welcome.

Paul.

[Gurce Isikyildiz]

I just happened to have a macbook at home and it happened to have a WinXP virtualbox on it. So I was just getting by with what I had :)

Sure, it was painful, but it at least gave me some assurance that the project was capable of being built under Windows/Cygwin.

Anyway, I'm moving onto the work Ubuntu pc now, less pain, and a faster machine, so hopefully things will be smoother now.

Daniel, I tried your Config app on VICE, worked fine there, nicely presented :)

Next, I wanted to try it out the M65 hardware. I wanted to use that "monitor_load" program, but just wasn't sure how. I suspected I would need to use the virtual .d81 attaching method?

./monitorload r -l /dev/ttyS4 -d mydisk.d81

But I don't get any feedback that the virtual disk gets attached... I tried stepping through the program a bit with gdb. I noticed that the virtual_f011_pending flag never seems to get set to 1. Is this a factor?

      if (addr==0xffd3078) {
        if((b[6+9] & 0x80) && !virtual_f011_pending) {  /* virtual f011 read request issued */

Maybe I'll just drop the .d81 onto the sdcard for now. Still, I wanted to get some learning curve underway with this monitor_load tool too.

[Daniel England]

Heya Gurce!  

Thanks for the feedback.

I'm just using the program loading options on monitor_load.  So:

monitor_load -r -4 <program>

Also, monitor_load works over the USB bus so you'll likely need to tell it that instead of the regular serial device.  I don't actually do that and I think it defaults to /dev/ttyUSB1 which works well for me.  It might be different for you because of using Cygwin or such?

The config program is presently reliant on the C64 Kernal so you need the -4 option.  I think its always going to need to run in "C64 mode" though (for simplicity and compatibility).

Daniel.

[Daniel England]

Gurce,

Try without specifying the device.  What does that do?

Also, why don't you ditch that WinXP VM and create one with Ubuntu?  I recommend using the x64 one as I've had some issues with ISE on the i386 version.

Daniel.

Gurce said:

Thanks for the monitor_load step.

I've given that a try as follows and it stalls in a similar fashion to my last attempt with using this tool:

./monitor_load.exe -l /dev/ttyS4 -r -4 /home/vets/Config/config.prg
sending R command to sync @ 2000000pbs.
sending R command to sync @ 2000000pbs.
sending R command to sync @ 2000000pbs.
sending R command to sync @ 2000000pbs.
sending R command to sync @ 2000000pbs.
Synchronised with monitor.

I think the /dev/ttyS4 device name is fine in this case as it is just what the virtualbox renamed the board's USB-to-serial device to be. I also confirmed that this device works with minicom/m65dbg, so it is communicating fine there.

Ah well, perhaps it's another quirk of the WinXP/Cygwin world. Sadly, I have no pure linux machine at home, so I'll just have to debug this and see why it stalls after syncing...

[Gurce Isikyildiz]

Hmm, if I don't specify a device, it'll default to a hard-coded value which won't work for me:

./monitor_load

Could not open serial port '/dev/ttyUSB1'
open: No such file or directory

But no worries, I managed to kind-of get monitor_load working via gdb, set a breakpoint on process_line() function and manually continue through it...

• gdb ./monitor_load.exe
• break process_line
• run -l /dev/ttyS4 -r -4 config.prg
• Then do "c" (continue) each time it breaks on the parsing of a received line
  

It seems that by slowing down the serial comms conversation in this fashion, it successfully loads the .prg!

I'll have to debug it further to get to the bottom of this, perhaps another day, exhausted now :)

--

[Gurce Isikyildiz]

Oh, as for creating an Ubuntu VM on my macbook at home, the idea has merit, just have to make the time for it :)

[Daniel England]

Oh!

Is the USB bus USB1 or USB2?  I imagine it would make a difference.  I don't think USB1 would be capable of the 2000000bps that the program is expecting to use.

Daniel.

---

From: Gurce Isikyildiz <gurce.is...@gmail.com>
Sent: 22 January 2018 19:08
To: Daniel England
Cc: MEGA65 Development
Subject: Re: Trying to compile, get errors

 

[Paul Gardner-Stephen]

Hello,

Basically USB serial adapters are good in theory, but horrible in practice. The problem here is that they capture lots of bytes together and send them all at once. You can't do that to the MEGA65 serial interface, as it processes at wire speed without any character or line buffer.  So the timed delays in monitor_load.c are really important, and if the OS groups multiple writes into a single USB transaction, things will go pear shaped.

The virtualised disk access using D81 files over monitor_load is still a work in progress.  Actually, it was working, and adding the real floppy drive has necessitated some re-work on that. Falk is working on it, and it will hopefully soon work again.

Paul.

[Paul Gardner-Stephen]

Hello,

It is USB2 as far as I am aware. In any case, 2mbit works generally well for me.

Paul.