z80ctrl - atmega1284 programming?

[Richard Deane]

I am trying to get my z80ctrl board working.

I have programmed the atmega1284 using a separate Minipro rom programmer, and the z80ctrl board works to the extent of responding to commands via the serial port (A tried) and installed on a small otherwise empty motherboard - powered through serial port. Using the Adafruit sd breakout board, dir will show contents of SD.

If I populate the motherboard with known working rc2014 cards then dir ceases to work.

J B Langston recommends programming via avr programmer so I bought a Pololu usb avr v2.1 programmer. When I attempt to upload, using Arduino IDE 1.8.5, the mighty core bootloader  or the mighty core sd cardinfo example I get the following error:

avrdude: stk500_recv(): programmer is not responding

avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

(actually has all 1..10 timeouts given).

(1) Has anyone had experience of this error and be able to suggest a fix?

I am confident I am using correct avr serial port. I am running on macosx and see port as expected when looking at "serial" terminal program ports. I use the lower of the two port numbers as instructed in the Pololu doc.

(2) Also if I burn to ATMEGA1284 using Minipro, does the hex file contain the bootloader, or is there any way from Minipro to set that to Mightycore?

I am using ATMEGA1284 rather than P variant due to purchasing error, and have the IDE set for ATMEGA1284. However I have not yet built z80ctrl.hex to alter from atmega1284p to atmega1284 - I suspect this may only affect subsequent programming via avr programmer through serial port.

(3) The doc is rather vague - is the serial port used by Make to download from pc to z80ctrl the first or second serial port of the avr programmer or the z8ctrl port A?

Richard

[Richard Deane]

I am making some progress. I believe I have mighty core bootloader installed.

When I do make on my mac osx it compiles the code seemingly ok, however make install gives the following error:

avrdude: ser_open(): can't open device "/dev/cu.usbserial-FTA9OFFR ": No such file or directory

 but I believe the port address is correct  as LS gives:

ls /dev/cu.*

/dev/cu.Bluetooth-Incoming-Port /dev/cu.usbmodem00219274

/dev/cu.serial1 /dev/cu.usbserial-FT1CHRG2

/dev/cu.usbmodem00219272 /dev/cu.usbserial-FTA9OFFR

I have verified that entry /dev/cu.usbserial-FTA9OFFR appears and disappears with each ftdi insertion and removal so I know I have the correct cable selected.

This is the serial port for the ftdi cable to z80ctrl port A

Any ideas on this? 

[Dave Kelly]

Please take what I'm about to say with a grain of salt because I experienced similar problems with OS X and the FTDI cable but your mileage may vary

The solution I found after a Google search was to remove the installed FTDI drivers because OS X has them built into the kernel now and the drivers I had installed a long time ago were conflicting with the kernel.

Take a look at https://www.decisivetactics.com/support/view?article=disable-appleusbftdi-driver which gives details on how to disable the Apple drivers.

If that doesn't work, you can remove any installed (non-Apple) drivers :

cd /Library/Extensions/

rm -Rf rm -Rf FTDIUSBSerialDriver.kext/

Rather than deleting it, I would move FTDIUSBSerialDriver.kext/ somewhere else ( or take a backup first ).

I don't recall if I needed to reboot but it's probably worth doing that afterwards.

Sorry if this is a little vague.

Dave

[Richard Deane]

Thank you for the suggestion, I think I will start by moving across to my win 10 32 machine and see if it works there. If so then update mac and try again. I keep win 10 32bit so I can run apps which won't run on win 10 64.

I had seen the decisive tactics article but did not expect that to be the cause.
Richard

[Richard Deane]

I have resolved the problem of how to program the z80ctrl atmega1284.

My AVR programmer (Pololu v2.1) needs configuring in the z80ctrl makefile, changing programmer from arduino to stk500v2.

I now have identical behaviour when programmed via ISP header and when programmed directly in Minipro tl866cs.

My Z80ctrl card now has the same behaviour as mentioned below, that standalone it can do dir of the inbuilt microsd but when plugged into backplane and other boards then if gets drive not ready.

I am working towards having a second backplane so that I can try various permutations.

I now have Steve Cousins design of z80 card and sio/2 card working and an unpowered backplane, but waiting for a powered usb hub and eventually get the backplane powered directly (overspent on Mouser until next month, then I can fix the backplane and build an IDE card). I want to rule out power supply issues as the reason why the z80ctrl sd breakout ceases when plugged into backplane with other cards.

I should note that I am still using the atmega1284 rather than atmega1284p and hence the z80ctrl card is presumably drawing more current; I cannot assume that JB Langston tested with 1284 - perhaps only 1284p works.

I now have a 1284p and so can switch over, reprogram and do further testing, but I'd like to try more with the current configuration first.

Richard

On Friday, 10 August 2018 08:16:15 UTC+1, Richard Deane wrote:

[J.B. Langston]

I'm glad you got the programmer working.  Did you see my earlier message about the problem you're having with the SD card? I replied to the first thread you created about it but you never responded. I suspect that something on the other board is shorting together pins 37, 38, or 39. These pins have SPI SCK, MISO, and MOSI signals exported on them and if the other boards have those pins connected together, either intentionally or via a solder bridge, your SD card won't work. You should check these pins with a continuity tester on the board that stops the SD card from working when it is inserted.

[Richard Deane]

Thanks,

Yes I did see the email but not had the chance to follow it up with diagnostics - I do have a 'scope (Philips - old but hopefully effective); however following in the direction you noted : I have built up a couple of new SCC backplanes, but not self powered, powered through ftdi, and I am still getting the problem. I've also built an SCC Z80 and SCC SIO/2 so if the problem is reproducible in all permutations then it points to my z80ctrl pcb build.

Do you know if the z80ctrl works with the scc z80 cpu + memory board?

I am waiting for a powered hub to enhance power supply through ftdi in case my pc usb is not driving it sufficiently - in a few weeks I shall also update one of the new backplanes to be self powered, components from Mouser, bumping up the order with IDE PCB components to hit free shipping. I use genuine FTDI cables so they should be transferring Vcc ok, but I prefer a powered backplane.

Aside from getting z80ctrl working I want to maintain one standard RC2014 CP/M 'puter and one ROMWBW so that I don't have to keep plugging and unplugging boards.

I am addicted to computers so I do have Mac OSX, Win10-32, win10-64, x86linux and RPI-linux, whichever suits CP/M support best (and a win9x &dos machine for myz80). At present Mac OSX is my preferred environment - It's been an interesting experience over the last year mostly switching from Windows to Mac but some apps have to be on Windows so can't switch completely.

I've got Runcpm on a teensy 3.6 - cute and working , but not had the chance to debug Altairduino on a Due - problems with sd card support.

I'm attracted to your z80ctrl design because of its support of PeterSchorn's Altairz80/simh build images.

Now if only someone would make an RC2014 video card with Amstrad PCW support and a rom bios for booting pcw disks :)

Did I say I was addicted? :)

I've had a career in software development/test but retired and wanted to tinker with some electronics - soldering etc - nice feeling when it works. 

I wrote a significant project management suite on an Ithaca Intersystems S100 Z80 CP/M system in the late 70s early 80s, using Pascal (excellent TCL Pascal, most others failed as the suite got larger) and with Magic Wand as word processor and programming editor, interfacing to IBM Mainframes  with Micro Integration 3780 package. Good fun. Then moved over  to Philips in Vienna (P2000C and Yes: development) CP/M and UCSD Pascal - had fun with Corvus networks. After that it was with Digital Research (DR DOS and Multiuser DOS) and then Novell, then over to Sydney with Citrix. I am retired now.

Cheers

Richard

[Spencer Owen]

On Mon, 13 Aug 2018, 22:03 Richard Deane, <rwd...@gmail.com> wrote:

Now if only someone would make an RC2014 video card with Amstrad PCW support and a rom bios for booting pcw disks :)

I might have just what you need. Kind of. Due to some overenthusiastic eBay bidding, I ended up with 2 Amstrad PCW9512 machines. Both fully working now that I've replaced the drive belts. So, apart from the "RC2014" requirement, it ticks the rest of your boxes and I really don't need both of them. Open to offers :)

Spencer 

[Richard Deane]

Many thanks for the offer, it is tempting but I only have a small box room for my office, desk pcs etc, so anything bigger than an Arduino is too much (RC2014 scraped in because it's flexible and home- built). I have to sidle in sideways as it is.

I had to dispose of old Philips P2000Cs and old classic Macs years ago - before I realised their actual or sentimental value. Just too many house/country moves to keep them.

A genuine Amstrad would be nice, but I get by with the Joyce emulator on my PCs. It's just that the Amstrad had such a library of software and cp/m-plus os, would be nice to have them run on an RC2014.

Cheers

Richard

[Alan Cox]

> A genuine Amstrad would be nice, but I get by with the Joyce emulator on my
> PCs. It's just that the Amstrad had such a library of software and cp/m-plus
> os, would be nice to have them run on an RC2014.

You would also need to emulate all the other I/O features, interrupt
logic, keyboard and the memory management unit to run much Amstrad PCW
stuff.

PCW's are easy to get hold of so it would probably be more useful to
build a buffered PCW to RC2014 interface for the rear connector. It
seems to have all the right signals. You can also build a knocked-down
PCW as the keyboard, mainboard and disks are easy to get and only need
5v/12v. Conveniently the video is on the rear connector although it
does need to be taken through a small circuit (see the UIDE board for
it) as it's a very weak drive off the ULA.

Alan

[J.B. Langston]

Yes I did see the email but not had the chance to follow it up with diagnostics - I do have a 'scope (Philips - old but hopefully effective); however following in the direction you noted : I have built up a couple of new SCC backplanes, but not self powered, powered through ftdi, and I am still getting the problem. I've also built an SCC Z80 and SCC SIO/2 so if the problem is reproducible in all permutations then it points to my z80ctrl pcb build.

If the SD card works until you put in some other board, then really the only explanation I can think of is that it's shorting together the SPI pins I mentioned.  I would not bother with a scope until you have tested those pins to see if they are shorted using a multimeter continuity tester.

 

Do you know if the z80ctrl works with the scc z80 cpu + memory board?

I haven't tested, and I'm not familiar with that board, but I think the answer is likely no. The z80ctrl needs full control over the Z80's clock and control lines so if there is any competing circuitry for those on the board, it will not work. If you can point me to a schematic, I will take a look.

 

I am waiting for a powered hub to enhance power supply through ftdi in case my pc usb is not driving it sufficiently - in a few weeks I shall also update one of the new backplanes to be self powered, components from Mouser, bumping up the order with IDE PCB components to hit free shipping. I use genuine FTDI cables so they should be transferring Vcc ok, but I prefer a powered backplane.

I agree that a separate power supply is best, especially if you plan to have more than a few boards.  But the problem with the SD card not working once you insert other boards really sounds like that board is causing a short on the SD lines to me.

[Steve Cousins]

JB: Schematic of my combined CPU+RAM+ROM+Clock+Reset module attached. Further details at scc.me.uk

Steve

[J.B. Langston]

Thanks Steve. From a quick review, it looks like this would have a few compatibility issues with z80ctrl, which could be worked around with varying levels of difficulty:

First, the reset IC (U7) and crystal (X1) would need to be left off the board.  Otherwise, they would fight with the AVR for control of the clk and reset lines.  Rodney tried the z80ctrl and Scott Baker's enhanced CPU board (which uses a similar set up), and confirmed this was a problem.

Second, z80ctrl is not really meant to require a ROM, and having the ROM at $0000 after a reset causes it some problems which I have experienced first-hand using Scott Baker's RAM/ROM board. When the Z80 resets it pre-reads the first byte of instruction from address $0000, and because reset signal also pages in ROM, the z80ctrl doesn't have a chance to page in the RAM again before the Z80 reads the first byte from ROM. In the case of uninitialized flash is $FF--a RST 38H instruction--which causes the CPU to immediately jump to 38H  and get stuck in a loop executing the $FF that is there.  To work around this, you can program the first byte of ROM to a C7, which is RST 00H. This way the Z80 will jump back to 0, and by the time the Z80 reads the byte, z80ctrl will have paged in RAM, so things can pick up where they should have, executing the reset vector written in RAM. 

Alternatively if both the ROM and RAM have the same first byte, it will work (for example both have a reset vector with $C3 at $0000).  Of course with a fully RAM-based board, this wouldn't be an issue.  Unfortunately, it's not as simple as just dropping a RAM chip in the ROM socket because the A15/A14/and WE# are all shuffled around. It would not be too hard to do some surgery to cut the traces for these pins and then run some bodge wires to the correct signals. This would allow you to have a full 1MB of RAM.  Another alternative would be to cut the traces on the RAM and ROM's CE# pins and swap them so that the RAM is paged in by default. But then again, if you're doing surgery on your board, there's not much point of having a ROM when the z80ctrl can pre-program RAM with whatever program you want.

The z80ctrl does have support for writing flash and for transparent paging of all 1MB of memory using Scott Baker's RAM/ROM board.  If this combined board works the same way, which it appears to, then it should also work with this. The correct base address for the paging registers would just need to be configured in the Makefile.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/zEVQ0_elPo4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/0b35bdad-98ef-45d5-86e0-adce4e4162e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Deane]

Some progress with Z80ctrl (hurrah!), but obviously not yet working correctly:

Using a simple SCC motherboard with  3 cards:

1) Z80ctrl

2) RC2014 Z80 v2.1

3) 64K RAM

a) I can do DIR of Micro SD and see hello.hex and cpm2.dsk (off peter schorn's site)

b) I can boot cpm2.dsk and get cpm signon and disk prompt A> followed by infinite stream of ^@, which is not halted by ctrl-c

c) I can do loadhex hello.hex then run 100 ; then I get an infinite stream of "hello, world" - I expected only one iteration.

I am using a genuine FTDI cable at 115200; running off a powered USB hub but similar if I use self-powered usb hub

Any thoughts?

Richard

On Monday, 13 August 2018 17:44:42 UTC+1, J.B. Langston wrote:

[J.B. Langston]

b) I can boot cpm2.dsk and get cpm signon and disk prompt A> followed by infinite stream of ^@, which is not halted by ctrl-c

You probably don't have the wait state jumper on the z80ctrl set correctly. This should be set in the left-most position (all I/O addresses).  Otherwise, the z80 doesn't wait long enough for the AVR to respond and you will get timing glitches with I/O requests to addresses outside of the selected range.  This often manifests itself as spurious serial input which shows up as a stream of ^@.

 

c) I can do loadhex hello.hex then run 100 ; then I get an infinite stream of "hello, world" - I expected only one iteration.

You may have an old version of hello.hex that does a RET instead of a HALT at the end. After loading the hex file, you can do a "disasm 100 130" and see if that is the case. If so, you can poke a 76 (HALT) at that location to fix it.

[J.B. Langston]

Oops, I meant right-most position, not left-most.

[Richard Deane]

Thank you for the tips. Gets better all the time - Jumper on right-most position (viewing from chip side) then CPM2.DSK boots CPM and MBASIC loads and runs ok

hello.hex is quirky, and I don't think hello.hex matches hello.asm. Gives "hhhhhello world" typically (instruction 109 is ret where I would expect halt). Will look into that when I've got asm tools on host pc so I can build asm to hex then xm down to z80ctrl.

Would be great if z80ctrl allowed simh hdir to work and r and w commands to transfer into and out of active simh disk from microsd while running the cpm os. :) then I could xmrx to microsd, boot cpm and bring file into cpm disk.

Clearly my card now works, and the problems are likely to be me on the learning curve of z80ctrl.

thanks

Richard

[J.B. Langston]

hello.hex is quirky, and I don't think hello.hex matches hello.asm. Gives "hhhhhello world" typically (instruction 109 is ret where I would expect halt). Will look into that when I've got asm tools on host pc so I can build asm to hex then xm down to z80ctrl.

Maybe I didn't commit the updated version of hello.hex. I meant to but I could have made a mistake. I will check it out after work.

 

Would be great if z80ctrl allowed simh hdir to work and r and w commands to transfer into and out of active simh disk from microsd while running the cpm os. :) then I could xmrx to microsd, boot cpm and bring file into cpm disk.

Yes, that's high on my to-do list. I've been more focused on the TMS9918 card recently but I will get back to it eventually.

 

[Colin Little]

Richard, my o/p

z80ctrl>base 80000

current base address is 80000

z80ctrl>loadhex hello.hex

loading from hello.hex

loaded 45 bytes total from 0100-012c

z80ctrl>run 100

hello, world

Yes 109 should be 'HALT'

80100   31 FF FF 21  1E 01 CD 0A  01 76 7E A7  C8 CD 13 01

80110   23 18 F7 F5  DB 10 CB 4F  28 FA F1 D3  11 C9 68 65

80120   6C 6C 6F 2C  20 77 6F 72  6C 64 0D 0A