Sometimes coming out of the BUSREQ mode, the process restarts somewhere else. So I have to figure out why. Not that it’s that bad. Bus everything should go Hi-Z before the BUSREQ goes high. I should ensure that happens.
I’m not sure why I have to issue a “fp reset’ after a ‘fp pins 1’. This issue is possibly related to the issue above.
I was working in 9600 baud on the serial port. My test to see if 115.2 kbaud worked. Yay!!! So I’ll switch to that. Twelve times faster. I will connect the RTS and CTS lines and use HW flow control. I’m not sure my little Z-80 can keep up with 115.5k otherwise.
I’m absorbing the nuances of the SDCC toolchain. It’s an open-source project so it has the pluses (within my budget) and minuses (hard to use) that one would expect.
I wanted to compile the SDCC toolchain. That required the boost library which is huuuuge. Eventually after figuring out user property sheets in VS 13 I got it to compile. But the sdar is not included. And it gives me the segmentation fault.
I could run this all in linux in VirtualBox but as of now, VirtualBox doesn’t work on Windows 10 and I upgraded to Windows 10. So now I’m trying to get it running on my cloud server. Learning wget and installing bison, flex, boost, g++, gputils, texinfo (for binutils) … Tech’in ain’t easy.
[Update:] Not sure how much fruit this is bearing. My cloud server, being shared, is configured to have no swap file. The RAM is the RAM. And I’m apparently running out of memory. I tried to remove the -pipe flag in a makefile, but that didn’t work…
Back to try to compile in Windows with Cygwin….