z80ctrl board. trials and tribulations.

[Jay Cotton]

For info leading up to this point see J.B. Lanstons post for a review on the

PCB.

Now on to bigger things...  sorta

I have the board working mostly.  Having some troubles with the z80 memory related functions.

See the attachment:  I can execute the altmon command, it stuffs memory with a binary (see listings).

I can see the operation on the analyzer.

However, the memory seems to be corrupted.  See the attachment.

I can list files on the SD disk, but have not attempted to run a program from the disk.  I suspect it will

fail for the same reason above.

So the state of things is, its almost there.  I will now start to drill in on this memory thing and see if I can

clean that up.  

I'll attach a couple of pix of the board and setup.

Here is a pix of the back plane with the control board, z80 cpu and ram.  The analyzer is plugged in to

the control signals on the back plane.

The ribbon cable is jumping all the extended bus signals over to the control board.

The other pix is the control board.  Note that I have a ziff socket for the atmega chip and should have used

sockets for the other chips ..  also I have the SD card board on a connector, so I can unplug it if needed.

Sticking out the side there is a sio to usb converter board.  Not required but brace and belt.  NOTE!!!!

The usb port CAN'T provide enough power for this system to run, you must have an external power 

source.

jc

[Jan S]

Hi Jay

For what it's worth...

From Your memory dump it appears that You may have 4 frozen ("0") bits .

xx0000xx  (x=alive)

First hex digits are 4, 8 or C, which indicate that at least the first to bits are alive.
Last hex digits are 0..3, which indicates that at least the last two bits are alive.

Best regards (and happy hunting)
Jan

[Jay Cotton]

Hi Jan;

I can confirm your analysis.  The 4 middle bits do not change during the fill command.

However, the bits are not stuck low all the time.  I did a run command and had lots 

of satisfying bus activity.

Right now I am looking at the atmega c bus direction bits and things like that.  

The write to memory code it surprisingly simple code.  That's the mark of a

grate programmer.   So it has to be something subtle or something I did to the

chip.  We shall see.

[Jay Cotton]

So far:

I checked the data bus signals from the atmega chip to the end of the bus.  All good.

I then changed out the atmega chip itself, no joy.

The documentation for the part is real specific.  Write ones to the DDRC register then

write ones to the DATAC register and get ones on the outside, except.  I get c3h .....

middle 4 bits are 0.

[Jay Cotton]

after a long session of digging for data on the internet, I found the solution.

The DATAC port is the possession of the JTAG thingy.  I found a check box 

on an obscure page in the programmer program...  And that fixed the

problem.

On to the next thing....

[Jay Cotton]

Got the altmon program running.  The jumper block needs to be set to position 2

this is j4.

Going to work on getting CP/M running next.

[Jay Cotton]

Another tidbit.  Looks like the memory must be cleared to zero befor

running altmon.  Had a real interesting time figuring that one out.  

[Colin Little]

Jay, I appreciate your fortitude in hanging in there with all these issues. I read with interest your problems & solutions. I hope we can get the benefit at some point to implement all the work that's gone into this by yourself and the author......... and have a fully operable system.

[J.B. Langston]

Jay, thanks for your perseverance on this. I was pretty frustrated and needed a break for a while so I'm glad someone else was willing to pick up the torch.  I am back from a 2 week vacation now and I think I will dig into this again and see if I can get it working using your mods to the board once I get a little free time.

[Jay Cotton]

Thanks,

Don't forget that JTAG thing.  I was a real showstopper.  Not certain you need my h/w mod, but you will need to change the SD_CS and IOX_CS logic in the program to fix it.

I made the mod, because I had the wrong schematic, and boy was the confusing.

So, my point is, try a s/w fix first.

JC

[Rodney Ross]

JB, Jay

From the Modifications on the board you  are using, You tied: 

1.  The ATMega Pin 4 (SPIA0) directly to the IOExpander Pin 11 (/IOXCS)

2.  The ATMega Pin5 (SPIA1) directly to the SD card Pin 7 (/SDCS)

 Looking at how the board was wired: 

/Enable	SPIA0	SPIA1	PIN9	PIN10	PIN11	PIN12
H	X	X	H	H	H	H
L	L	L	H	H	H	L
L	L	H	H	H	L	H
L	H	L	H	L	H	H
L	H	H	L	H	H	H

Trying to follow along to make the fewest cuts or possibly only a software change. It looks like using only SPIA1 and leaving SPIA0 Low would allow the 139 to work as connected???

With SPIA1 Low enabling the I/0 Expander and HIGH enabling the SD Card.   

I wish I had all the parts to test,   Hoping to get them in tomorrow.  

[J.B. Langston]

It's been over a month since I looked at this but I think I may have already fixed the CS logic in the code but I'm not sure I checked it into github. I do remember futzing around with something about that. I'll have to get back into it and refresh my memory.

[Jay Cotton]

Rodney:  There needs to be 3 states at least for the CS bits.

SD_CS true  false

IOXCS  true false

BOTH OFF

[J.B. Langston]

I looked back at my code, and I had modified defines.h to correct the issue with the CS address lines in software, but I hadn't checked in the changes to github yet. Here is what I changed:

jblang@cloud9:~/winhome/Retro/Z80/z80ctrl$ git diff defines.h

diff --git a/defines.h b/defines.h

index b92ea1a..3e402b4 100644

--- a/defines.h

+++ b/defines.h

@@ -22,10 +22,17 @@

 #define CSADDR 3

 #define CSADDRMASK ((1 << CSADDR) | (1 << CSADDR+1))

+#ifdef CORRECT_SPIADDR

 #define IOX_SEL SPI_PORT = SPI_PORT & ~CSADDRMASK | (0x0 << CSADDR)

 #define SD_SEL SPI_PORT = SPI_PORT & ~CSADDRMASK | (0x1 << CSADDR)

 #define AUX1_SEL SPI_PORT = SPI_PORT & ~CSADDRMASK | (0x2 << CSADDR)

 #define AUX2_SEL SPI_PORT = SPI_PORT & ~CSADDRMASK | (0x3 << CSADDR)

+#else

+#define IOX_SEL SPI_PORT = SPI_PORT & ~CSADDRMASK | (0x0 << CSADDR)

+#define SD_SEL SPI_PORT = SPI_PORT & ~CSADDRMASK | (0x2 << CSADDR)

+#define AUX1_SEL SPI_PORT = SPI_PORT & ~CSADDRMASK | (0x1 << CSADDR)

+#define AUX2_SEL SPI_PORT = SPI_PORT & ~CSADDRMASK | (0x3 << CSADDR)

+#endif

The correct chip select lines were being asserted. The LED lights up when it attempts to access the SD card, but something else is wrong.  I also confirmed that it is able to read from the IO expander correctly over SPI by pulling various data pins high or low and dumping the memory, then confirming the results match the pins i had pulled high or low.  I will try dig back in now and figure out the problem.

[Jay Cotton]

The JTAG bits are using the 4 middle bits of the C port.  That may be the issue.

[Rodney Ross]

Agreed,  I was trying to show that the Chip select(s) were toggled with one line as wired into the 74HCT139.  As long as the other line was kept low,  Bringing that other line high would disable both the chip select of the I/O expander and the SD card.    Your modifications showed that each is an individual  chip select,  which seems to be working,   Unless they are both active (low) at the same time..

As wired on the board through the 74HCT139. SPA1 will select either the I/O expander or the SD Card as long as SPA0 is low Bringing SPA0 High will disable both of them.   

I see JB responded while I was typing this,  Just trying to document the Hardware side (Wired vs your changes) 

[J.B. Langston]

I assume that you're referring to the JTAG interface on the AVR?  If so, I have programmed the AVR with the MightyCore Arduino bootloader (https://github.com/MCUdude/MightyCore), and it should already have set the fuse bits to disable JTAG.  I was using the same AVR chip on a breadboard and it was working, so I don't think that is the problem. The problem only started happening when I built the PCB.

[J.B. Langston]

Yes, the idea was for SPIA0 and SPIA1 to select 1 of 4 chip select lines. 00 should be the IOX chip select, 01 should be the SD chip select, and 10 and 11 should be AUX1 and AUX2 chip selects, respectively, which are unused on the board itself but are carried out to the expansion bus to be used by external cards. The problem is I accidentally crossed the SPIA0 and SPIA1 connections between the AVR and the 74HCT139.  So address 00 and 11 work as expected, but 01 and 10 are reversed. This means 01 is the AUX1 chip select and 10 is the IOX chip select.  My patch updates the code to match the incorrect wiring.  When my code is not actively using the SD card or IO expander, it selects the AUX2 (11) line.  Since two address lines only encodes 4 states, and there is no separate enable line, I am treating AUX2 (11) as disabled. Since there is nothing connected to this line, it should be fine.

[J.B. Langston]

Sorry, I said 10 is the IOX chip select, but I meant that 10 is the SD chip select.

[Jay Cotton]

Think I'll replace the hacked to death chip and try your code change.  That seems like it will

do the trick.

Are you able to get the 'disk' up and running now ?

[J.B. Langston]

No, it's still not working, and I didn't get around to hooking up my oscilloscope tonight.  Also, the IO expander seems to be only partially working.  I hooked my board up in the backplane with the 64KB RAM board tonight, and I can successfully fill the RAM and read it back, but apparently some of the address lines are not working correctly because when I try to fill only certain subsets of the RAM, more of it gets overwritten than expected.  I'm not sure what to make of these two problems taken together. Hopefully the scope will shed some light. Unfortunately I don't have a logic analyzer or the upgraded software on my scope that will decode SPI traffic so it will take some effort to do it manually.

[Jay Cotton]

I think my code base is rather stale.  When you get a chance can you do a push please.

tnx

jc

[J.B. Langston]

Done. The only change was the patch I emailed last night though.

[Jay Cotton]

Built and tested.

SD seems to be working.   Need to try the hexload or cpm test.

z80ctrl can fill and dump memory anywhere and get good results.

altmon loads and work.

altmon dump memory seems to be showing stuck bits in low ram.  high ram seems to be o.k.

some of the commands are a bit flaky.  Found that you MUST clear out memory before running

altmon.  I suspect there are coding bugs, assumptions that ds = 0 some how.  

[J.B. Langston]

I've done a few more troubleshooting steps, but nothing bearing fruit.  Have you had any luck getting CP/M to boot? I suggest using this disk: https://schorn.ch/cpm/zip/cpm2.zip (there are many others on this site that will also work). Copy cpm2.dsk from the zip file to the SD card. You will need to mount it using "mount 0 cpm2.dsk", then "sboot" to boot it using the simh bootloader.

[Rodney Ross]

JB, 

     I have built a board and have it working!   Just got it to boot CP/M this evening.   even mounted the games disk.      Like Jay I have better luck using z80ctrl to fill the RAM with Zeros (0).  then mounting and shooting from there.  

[Rodney Ross]

My board is RED!    Also notice that my Serial adapter has power on a different pin, which caused a bit of grief trying to upload to the board...   

[J.B. Langston]

That's encouraging to hear.  I may build a second board and see if it works better.  It might be easier than trying to troubleshoot this one as I have all the parts needed to build a second one.

Just to clarify, are you using the unmodified board with the unmodified latest version of z80ctrl that I checked into github?

I'm puzzled about why it would be necessary to fill the memory with 0s before running anything. When I was using the system on a breadboard, it worked fine no matter what was in the memory.  Whenever you issue a command like altmon, sboot, or dboot, it should overwrite the memory with whatever you specified at the necessary address and then set the jump instructino to that address at the reset vector at the start of memory, so it really shouldn't matter what is elsewhere in RAM.

[Jay Cotton]

Did the hexload test, that is working.  I'll try the cpm test next.  Looks like Rodney has it all working now.  The sweet smell of success !

jc

You may want to try an external power supply in addition to the usb port.  Something that is known to supply 5V at about 200+ ma.

I am seeing 300-350 ma on my RC2014.  I do have 9 heavy current users in there.

jc

[Jay Cotton]

The under laying assumption is the DS makes zeros in memory.  This is FALSE.  It just advances the pc address to the next location, so uninitialized variables.

I do see the confusion however.  You would expect a programmer to write zeros into locations that MUST be a zero.  

Anyway, off to cpm land for a try at that.

jc

[Jay Cotton]

BTW:  I am still running at 5607 baud.  Need to track down the clock/baud rate problem.  What are you seeing on your system ?

jc

[Rodney Ross]

UnModified board (excuse the Iron to the socket on the I/O expander)..  Last Github release, MightyCore on the 1284P.       My RAM board is a modified Dr Scott RAM/ROM board hard coded for RAM only. and my Z80 is 10Mhz version on Dr Scott enhanced Z80 with the clock pulled.    I got it running about 5 minutes before my post.   Just long enough for my 8 year old to want to play adventure!    If you can't get it to go,  I'll send you my working board.   You put so much work in its not fair for you to not play too..   

[Rodney Ross]

115200.   

[J.B. Langston]

I'm using an external power supply, so that's not it.  

I don't get why it would work without initializing the memory to 0 when I had it on the breadboard though. Maybe I was just lucky, but I don't think so, I ran with it for a very long time in this configuration, removed power many times and booted straight up without initializing, so the memory should have been in many different random configurations.

I did have a big realization about one problem I was having with the memory. Memory seemed to be working, but only the upper half.  I just realized that the RAM board does NOT have a pull-up resistor for the page pin, so if you attempt to use it without the ROM board, you need to put a pullup resistor between the Rst2 (Page) pin and 5V.  My board should have included that since it's intended to be used without the ROM, but I missed it.  Now that I've done that, loading and reading memory seems to be working correctly, for all 64KB.  However, ALTMON is still not running, even if i zero out the memory before hand.  When I run ALTMON and reset, I can inspect memory and see that it loaded correctly, so I suspect I have a problem with I/O.

Of course SD is still not working, so I suspect that is a completely separate problem.  More to come...

[Rodney Ross]

JB, 

    I've still not had a bunch of time on this little guy,  but I noticed that its the state of the z80. (Dr. Scott Baker's board has LED's and an auto reset circuit).  If the LED's are stuck on its like z80ctrl did not get the board reset.   A reset 0 also work as well as a dump 0.   I'm guessing I'm hitting the reset circuit in my case...    

[J.B. Langston]

Your RAM board is probably different than mine. I'm using the standard one that Spencer supplies with the RC2014 Pro kit, and it uses the Rst2 line on the bus as a page signal, which will page out the bottom half of RAM if the ROM should be loaded there (the default initial state when you're using the kit as supplied). However, there's no pullup for this on the RAM board so it will float if you take out the ROM board and behave unreliably.  The Rst line that resets the Z80 is a separate bus line and unrelated to this problem.

[J.B. Langston]

Got pretty bad allergies so I think I am going to call it quits tonight. Hopefully I'm feeling better tomorrow and I can try putting together another board. I do appreciate your offer to send me yours, but I am hoping I can figure out my own board and get it working.  Now that I know there's nothing inherently wrong with the design and it's working for other people, I feel encouraged to keep trying.  Maybe I just have a solder bridge or a bad solder joint somewhere on my original board...

[J.B. Langston]

I tried putting together a new board last night (just the minimal parts to test the AVR and SD card, did not install the 74HCT74 or the MCP23S17), but to no avail. It still cannot read the SD card.  I also hooked up the oscilloscope to the CS, MISO, MOSI, and SCK lines on the SD card and noticed that the MOSI line seemed to be picking up a lot of noise from the SCK line.  I measured the resistance between SCK and MOSI with my multimeter and I see a resistance of only 300K.  Resistance between other pins is much higher, around 3M or more.  I also measured the same resistance on a second SD breakout board that I had not yet soldered into the PCB, so maybe it's normal. The same SD breakout worked previously on my breadboard but I never looked at it with an oscilloscope or measured the resistance between pins.

I guess the next steps would be to try putting printfs in the mmc_avr_spi code and try to look at the bytes being sent and received to see if they make sense. I could also try hooking up the circuit on a breadboard again and compare.  Guess I will do this eventually but I can already feel my motivation waning again. So frustrating!

[Jay Cotton]

I have most of it working.  I may have a memory board bug, can't tell yet.

I can run altmon after clearing ram to 0.  I can load a program from the cf card.  BUT I can't boot the cp/m disk.  

After the assign, I say sboot and then when I look at ram its got 00,39,  From end to end.

Something went haywire.  Still having some odd things in low ram first 2 k seems a bit flaky.

I can get some measurements for you latter today.   maybe some analyzer traces.

Don't give up on this, its too cool to just drop it.

jc

[Jay Cotton]

Meet me on IRC ##rc2014  so we can speed up the conversation.

[J.B. Langston]

What RAM board are you using? Is it the standard 64K RAM module (https://rc2014.co.uk/modules/64k-ram/)?  If so, did you see my earlier comment about needing to put a pullup resistor from 5V to the Rst2 pin, and have you done that?  You need to do that in order to prevent the lower half or RAM from being accidentally paged out by the floating pin.  If you haven't done that yet, I suspect that may be your problem.

What's your nick on IRC? I've joined as jbl3 but may not stay for long tonight. We can meet up again later to discuss if I miss you.

[Jay Cotton]

Here is some chitchat on the spi bus.

[J.B. Langston]

Rodney, do you have any spare PCBs from your run?  I am really starting to think maybe I got a bad run of PCBs.  I have tried it on two separate PCBs from my run of 3, and it doesn't work. Tonight I wired the AVR and SD card back up on a breadboard using the same AVR/74HCT139 chips, SD breakout, and SD card pulled from the sockets on the PCB, and it works on the breadboard. I had my PCBs manufactured by OSH park, and so did Jay. Jay's SD card is working but he's still seeing some flakiness with the memory.  Since your board is red I can tell you must've used a different manufacturer.

[Rodney Ross]

I have 9 boards left,  I did my run with other boards at SeeedStudio (Fusion service).   Would you like me to build another up to a point of testing  SD functionality?  Or would (and Jay) just like a blank board.   My boards are HASL (tin) and not EING (gold) like the OSHPark boards.   Let me know how I can help.   

[Rodney Ross]

Replying to myself,   I now have 8 bare boards left.  At lunch today I quickly built another board,  I don't have a row of double-row right-angle headers so I only tested to make sure the SD module was recognized and I could do a directory.   It was working that far (at 115,200)  so hopefully we can make this a go for both of you..  

[J.B. Langston]

If you don't mind sending me one of yours, that would be great!

[Rodney Ross]

J.B. 

    Message sent to your Gmail account.    

[Rodney Ross]

Jay,

     Did you get any further with the RAM issues or CP/M or your baud rate?  

[Jay Cotton]

No.  Stopped working on it just now.  BTW:  can you mail be a board.  I'll build it out

and run tests on it.   PM me the cost and shipping and I'll give you the shipping addr.

tnx

jc

[Rodney Ross]

PM sent..

[J.B. Langston]

I got Rodney's board (thanks!) and tested it out. It still didn't work. The good news is I found the problem and fixed it.  The problem was a fault on my Backplane Pro. There were 0 ohms resistance between pin 37 and 38 on my backplane. This is where my board exports the SCK and MISO signals, respectively, which explains why I observed such heavy crosstalk between those lines.I cut the traces to pins 37 and 38 on the backplane until I isolated the problem to slot 11. There is no visible solder bridge but the pins are definitely connected somehow.

I should have tested my board out of the backplane before this but I never did because I needed the backplane to provide power.  I made an error in the original design of the board so I couldn't provide power from my FTDI adapter.  So now both Rodney's board as well as my originals work.  I'm frustrated with myself that I didn't try something that in hindsight seems so obvious but I'm happy I finally have it working and I'm very grateful to Rodney for sending the board. 

[J.B. Langston]

Further test results:

- I can load hex files and boot cpm disks with or without first clearing the memory, and it works both ways.

- The pullup resistor on the page line doesn't seem to be necessary.  It has been stable running without it.

- I have been able to load complex programs such as zork, catchum, and ladder, and play them for a decent period of time without any crashes.

- I have tested my board in conjunction with Ed's YM2182 sound board, and it works but the music is even faster than before because the CPU is now running at 10 instead of 7 MHz. I need to implement interrupts to get it to play at a correct rate.

[Rodney Ross]

J.B. 

Awesome!   I also built another z80 module without the Auto-Reset section, actually its only the z80 and bus.   Now I don't have to "fill memory" before I can just mount and sboot.  CP/M comes up every time.   

Thank you so much for making this and not giving up.   

Thanks to Jay also for keeping up with the debugging before my parts came in.  Shows the power of our little community.   

 
Since you control the speed of the clock, via the ATMega,  could the base clock rate be changed from z80ctrl monitor?  May be useful for some of the older games.   

[J.B. Langston]

Awesome!   I also built another z80 module without the Auto-Reset section, actually its only the z80 and bus.   Now I don't have to "fill memory" before I can just mount and sboot.  CP/M comes up every time.   

When you say without the auto-reset section, I think you mean the reset diode for the Z80 (D3) and not the AVR auto-reset capacitor (C7), correct?  That may be something specific to the non-standard RAM board you are using; I haven't had that problem with the standard 64K RAM board I got from Spencer.  Next time I place an order to Mouser, I will get the necessary parts for the RAM/ROM boards you sent me so I can check this out.

I ask about the AVR auto-reset because I actually found a problem with it last night on the first board I built. The DTR pad of the Serial 1 connector (J5) was shorted to the GND pad. The symptom was that the AVR would not automatically reset for programming (I had to hold down the reset button and let i up after I started avrdude).  I'm sure it was also not good for the FTDI chip to have DTR constantly shorted; I'm surprised it didn't burn it out, frankly.  I fixed it by cutting the DTR trace on either side of the GND pad, and then soldering a bodge wire from the DTR pad to the DTR side of C7.

I think I caused a manufacturing defect by running the DTR trace between the Serial 1 pin holes and the edge of the board. There was not really enough space to comfortably do this and it turns out the solder mask for the ground pin did not cover the DTR trace, so when I soldered it, I created a solder bridge between the two.  I verified this on the first OSH park board I built as well as the third unbuilt board, but it is not the case on the second one that I partially built.  I think the tolerance is close enough that it could vary from board to board.  This doesn't seem to affect any of the boards you sent me; in fact the solder mask tolerances on those boards seem better than the ones from OSH park in general.

When I get time, I am going to update the README with (among other things) a list of known issues with the REV1 board, so if you find anything else do let me know. All the known issues at this point:

- I accidentally swapped the position of the CTS and VCC pin on the serial connectors. This doesn't affect anything unless you try to power the board from the serial connector by jumpering JP1 or JP2. You can work around it, as you found out, by crossing the CTS and VCC wires running from the FTDI adapter to the Serial connector on the board.  I simply left JP1 and JP2 unpopulated on my board so it doesn't matter.

- I accidentally swapped the position of SPIA0 and SPIA1 on the 74HCT139N.  As we discovered earlier, this can be fixed in software by swapping the definitions for SD_SEL and .AUX1_SEL in defines.h.

- The aforementioned problem with the DTR line in the AVR reset circuitry.

- Although it turned out not to be an issue at the 10MHz top speed of the SPI bus, the layout of the SCK track is not optimal. SCK runs to the SD card first and then back to the IO expander, whereas MISO and MOSI run to the IO expander and then to the SD card. At higher frequencies, the differences in length could cause signal skew and interfere with the operation of SPI.

- Mislabeled/mismatched values for C2 and C3, which you pointed out in the private email we exchanged. (They should both be 18 pf, at least for the crystal I used, but the value doesn't really seem critical.)

In addition to documenting these, I have checked in a new revision of the PCB to Github that fixes these problems.  I probably won't bother to get another run of boards made until I have some other PCBs to order at the same time though.

Thank you so much for making this and not giving up.   

Thank you and Jay for all the encouragement. I probably would not have continued without it (at least for quite some time).

  

Since you control the speed of the clock, via the ATMega,  could the base clock rate be changed from z80ctrl monitor?  May be useful for some of the older games.   

Yes, the clock rate output by the AVR is determined by the settings in clk_run in bus.c.  First, it is affected by the clock source bits (CS20, CS21, CS22) assigned to TCCR2B. The default value is prescaler of 1. Selecting a higher prescaler will result in a slower clock. The other values are documented in the AVR datasheet if you search for CS20.  Secondly it is affected by the values assigned to OCR2A and OCR2B. The clock output is toggled on when the counter reaches OCR2A and toggled off when the counter reaches OCR2B.  The counter also resets itself to 0 when it reaches OCR2A. With the default settings of 1 and 0, respectively, it toggles the Z80 clock on and off for every other AVR clock cycle (the fastest possible clock rate via PWM).  Increasing the values of OCR2A and OCR2B will also result in a slower clock.  To keep the duty cycle of the clock near 50%, it is necessary to maintain a ratio OCR2A+1 = 2*(OCR2B+1). When I get a chance I will work on a monitor command to make changing this easier.

My todo list at this point (just in the order they occurred to me, not necessarily the order I'll work on them):

- Monitor command to control Z80 clock rate.

- Monitor command to load and save binary files to and from memory.

- Monitor command to disassemble data in memory

- autoexec.bat file to be run by monitor at startup.

- Disk convenience commands for the monitor (erase files, create blank disk images, change directory, etc.)

- Improve Z80 debugger to decode assembly operands and output them in opfetch watch mode (mostly done; just needs more testing before checkin).

- Improve Z80 debugger to allow single stepping of individual instructions rather requiring multiple and varying steps per instruction due to the differing number of clock cycles for different instructions.

- Implement DMA for disk emulation so that the AVR will copy an entire sector of data to memory at a time instead of one byte at a time. This should speed up the disk performance dramatically.  It will also require a custom CP/M BIOS so it will be a considerable effort.  

- Implement pass-through timer interrupts for the Z80. This will allow more accurate timing e.g., for playing music on Ed Brindley's sound board.  Due to the INT pin being on the IO expander, the minimum timing resolution will be limited, but sub-millisecond resolution should be doable. Microsecond resolution is probably not.

- Implement interrupt-driven serial with a ring buffer and software flow control (XON/XOFF).  The AVR doesn't support hardware flow control, and currently it's easy to overrun the buffer by sending data too fast (e.g., via copy/paste or XMODEM).

- Implement a second serial port so that debugging can be on a separate console from Z80 program output.

- Possibly implement PS/2 keyboard interface on Serial 2 header (mutually exclusive with above, configured via compile-time or run-time configuration).

- Fix bug that causes monitor CLI to go into an infinite loop spewing z80ctrl> repeatedly when the HALT button is pressed while the Z80 is outputting something.

- Add other SPI peripherals and implement I/O port interfaces to them for the Z80. Examples: real-time clock, GPIO, 7-segment display, LCD display, etc.

- Possibly emulate other disk formats or peripherals.

- Investigate RomWBW support.

I will add this list to the README too when I update it.  I would welcome suggestions for additional features (although I don't promise I will implement them myself).  I would also be thrilled with pull requests, but if you're interested in working on anything, let's coordinate so we don't duplicate efforts.

Now that I have this working, I also want to build my TMS9918 video board prototype on a breadboard (I already have the parts), and if it works, have the PCB I've designed manufactured. See https://github.com/jblang/rc9918.

Thanks again guys!

[J.B. Langston]

Made an overview video of the final board here: https://www.youtube.com/watch?v=_iZxZO_yfaE

[Rodney Ross]

J.B. 

   No,  I was talking about the reset circuit on the z80 module (Remember I was using a Scott Baker enhanced z80 board that has a surface mount reset circuit that was battling with your board trying to control the reset line..  Thus the problem and if I toggled memory or probably even reset the z80ctrl board after the z80 had done its reset everything was fine...    So I've not found anything I had to change on your board but because I was not using the Spencer enhanced z80 I was running into a problem with the onboard reset on the z80 card...  (I think I sent you one of those z80 cards too,   Its the little 4 pin surface mount part...     Without it the boards don't fight and it works as it should !!!

[J.B. Langston]

Readme and schematic updated at: https://github.com/jblang/z80ctrl

[Jay Cotton]

J.B.  Thanks for the updates, and the heads up on the z80ctlr loop message.  Thought that one was mine.  

Rodney I have not yet received the board.  Did not come in as of Saturday.  Expecting it monday.

Looking forward to the next thing in line for this board.  Really like what it does for debugging programs.

J.B.  Perhaps if you want to farm out some of the s/w work, I can contribute as needed, no point in

burning out on the project.  I'll bet Rodney can help also.  

c u soon

jc

[Richard Deane]

I am very interested in being able to run CP/M-3 (CP/M-PLUS) on RC2014, and as SIMH (Altair Z80 Peter Schorn) has images for a banked memory version of CP/M-Plus I hope that your Z80ctlr will support that.

Has anyone tried it?

Will you be publishing a BOM (perhaps with Mouser part numbers) to match a finalised z80ctlr PCB (RC2014 format)?

I had also wondered if the new LiNC80 SBC would support CP/M-Plus but I think that the banked-memory management is insufficient (2nd 16k block not banked if I interpret the memory layout pictures correctly). If that is the case then it makes the z80ctlr more attractive.

Richard

[Steve Cousins]

Hi Richard

The LiNC80 SBC has a mechanism to switch the ROM out of the memory map giving you a full 64k bytes of RAM, same as the RC2014 paged ROM and RAM board combination.

The ROM socket supports up to 64k bytes of ROM, divided into four 16k byte banks. Anyone of the four can be selected in software. 

Therefore you can page in any one of the four ROM banks or just have 64k bytes of RAM.

The LiNC80 also has prevision for paging RAM beyond 64k, but that add-on is not available yet.

Steve

[Colin Little]

Hi JB, I have followed this product closely with the associated support posts & I would like to build one. I successfully built the Hackaday  z80 project - https://hackaday.io/project/19000-a-4-4ics-z80-homemade-computer-on-breadboard and was able to burn the Atmel on my TL866a. This will also burn the ATMega you are using, I prefer not to go down the Mighty core route (unless I have to) - so  can this be achieved in like manor??

On Saturday, 5 May 2018 23:24:03 UTC+1, J.B. Langston wrote:

[J.B. Langston]

J.B.  Perhaps if you want to farm out some of the s/w work, I can contribute as needed, no point in

burning out on the project.  I'll bet Rodney can help also.  

Since you are well versed in 8080 assembly I thought writing the custom CP/M BIOS for the DMA disk project might be a natural fit for your skills.  

I haven't started implementing anything yet but I have given it some thought...

This is the API that the CP/M BIOS implements for disk access:  

jmp home ;move head to home position

jmp seldsk ;select disk

jmp settrk ;set track number

jmp setsec ;set sector number

jmp setdma ;set dma address

jmp read ;read disk

jmp write ;write disk

I had planned to implement separate ports for directly writing the disk, track, sector, and dma address hi/lo bytes, as well as another command/status port to initiate the read or write transfer using the values written to the other ports, or to check for a status code. Using just a single control port and a memory buffer for the disk, track, sector, and dma address might be a little faster since it only would require a single IORQ as opposed to 6, but since the cost of writing to the ports is amortized by a large block transfer, I don't think the difference would be very noticeable, and I would prefer to keep things simple.

CP/M's native sector size is 128 bytes but it also has the concept of deblocking where the disk can DMA transfer a larger block and then CP/M can read the 128 byte sectors out of that.  CP/M provides example blocking/deblocking algorithms: http://www.gaby.de/cpm/manuals/archive/cpm22htm/axg.htm.  I believe fatfs already caches 512 byte blocks from the SD card in the AVR's RAM, so the only real performance gain to be had here would be the reduction of IORQs by a factor of 4. Since pulling a 128 byte sector at a time would already improve the current situation by a factor of more than 128, I am not sure how noticeable an improvement it would be.  Like I said before, I would like to keep things simple, so I would rather see the straightforward implementation done first and then move to the deblocking algorithm later if necessary.

FYI, I also found a really great book on CP/M programming, helpful both for writing a custom BIOS and writing programs that run on CP/M: https://archive.org/details/TheCpmProgrammersHandbook. What I've read of it so far is much more comprehensible than the official CP/M manual.

[J.B. Langston]

I am very interested in being able to run CP/M-3 (CP/M-PLUS) on RC2014, and as SIMH (Altair Z80 Peter Schorn) has images for a banked memory version of CP/M-Plus I hope that your Z80ctlr will support that.

Has anyone tried it?

I have not tried it and I am pretty certain it wouldn't work out of the box.  However, It would be possible for the AVR to implement a virtual memory paging facility where the Z80 requests a different page of memory via an IO port and then the AVR loads that page from disk. The performance of this scheme remains to be seen. The time it takes to fill the RAM with a constant value is on the order of milliseconds.  I have not benchmarked the time it takes to read a full 64K or even 16K from SD card over SPI, but I imagine it would also be on the order of milliseconds.  The theoretical maximum data rate for the SPI interface is around 1.2MB/sec, which would put the time to read a full 64KB from disk at about 52 ms, but reading from the SD card is going to have some command overhead for every 512 byte block so I'm not sure what the actual achievable performance would be.

I had already given some thought of implementing something like this for RomWBW support, and supporting CPM/3 native paging would probably not take that much effort.

 

Will you be publishing a BOM (perhaps with Mouser part numbers) to match a finalised z80ctlr PCB (RC2014 format)?

Jay published a digikey parts list on another thread a while back: https://docs.google.com/viewer?a=v&pid=forums&srcid=MDg4ODQwMTE2ODM0ODg2OTc5MTYBMDYxMjQ0OTAwNDMxMzE1MTEyNTYBd3dvUkxweVlBd0FKATAuMQEBdjI&authuser=0

I just gave it a once-over and it seems accurate at first glance but I haven't reviewed it line-by-line.

The changes I made to the board to correct the original defects so far have not affected the BOM; they just involve rerouting some traces on the PCB.  If you want the new REV2 board, do not use the previously uploaded PCB at OSH park. Check out the latest kicad_pcb file from Github and upload that for your order.  I will share a new version of the PCB on OSH Park once I'm fairly certain there are no more changes needed.  Keep in mind, although the REV1 board has known defects, it also has known fixes. REV2 is completely untested at the moment, although I would welcome some intrepid testers to give reports.

[J.B. Langston]

This will also burn the ATMega you are using, I prefer not to go down the Mighty core route (unless I have to) - so  can this be achieved in like manor??

I haven't tested it but there's no reason you couldn't burn z80ctrl without a bootloader. I believe Jay may have tried this and he initially ran into some trouble with fuse settings (JTAG was enabled and interfered with some of the pins on the port used for the data lines, I believe).  As long as you get those right, I think it should work though.  Jay can you confirm if you got it working without the boot loader eventually?

On the other hand, a good reason to use the bootloader is so that you can flash the AVR with new versions of z80ctrl without extracting the chip. The board doesn't have room for an ICSP header, so the only way to program it without extracting it is over the UART using a bootloader.  The board is packed pretty tight so I also doubt there is clearance for a ZIF socket either.  The only price you really pay for using the bootloader is a second or so at startup.  You can program the chip directly from avrdude so it doesn't require the arduino IDE.

[Richard Deane]

thanks - useful update.

p.s I have the Andy Johnson Laird programmers handbook you mention above from the first time around! Good book, and managed not to lose it after a lifetime of 15 house moves. It is often available second-hand in a physical copy.

Richard

[J.B. Langston]

The changes I made to the board to correct the original defects so far have not affected the BOM

One small correction to this; the schematic originally had a typo specifying a 20 pf and 22 pf load capacitor on either side of the crystal, and Jay's BOM copied this.  In actuality the crystal I used calls for 18 pf. The value does not seem critical and I have also successfully used 20 pf load capacitors. It's probably best not to put unbalanced (20 pf/22 pf) load caps on the crystal though.

[David Roper]

Do you have any boards left ?

[J.B. Langston]

I don't really have any extras to spare currently. Rodney might; he got more made than I did.

If not, I am looking for testers of the new REV2 of my board, which has not been manufactured yet, but should solve all the known issues with the current REV1 board.

[Jay Cotton]

Should we update the BOM for the new board.  

[David Roper]

Can I reserve a rev 2 board when available

[J.B. Langston]

Should we update the BOM for the new board.  

The BOM didn't change, except to correct the value for the crystal load capacitors C2 and C3 (18 pf although 20 also works) .

[J.B. Langston]

Can I reserve a rev 2 board when available

I'm not currently planning to sell the boards directly.  You can order the from OSH Park or any other PCB manufacturer you prefer using the PCB design in https://github.com/jblang/z80ctrl/tree/master/hardware.  OSH Park will accept the kicad_pcb file directly; other manufacturers will require you to generate gerber files from KiCad and submit those.

I will also add the caveat that I haven't tested REV2 yet.  REV1 has known problems but also known solutions. The changes I made to REV2 were fairly minor,  specifically to address problems found in REV1, so it should be pretty low risk but until someone tests it, we won't know for sure. 

I haven't ordered any REV2 boards and I am probably going to wait to do so until I have some other PCBs to order at the same time.  At most of the chinese manufacturers (e.g., Seeed Studio) the shipping cost almost always outweighs the cost of the board so it pays to order multiple boards at the same time.  OSH Park has free shipping, but also charges almost $40 for a run of 3 boards.  Other manufacturers will generally charge much less for a minimum of 10 boards, but shipping from China is usually $15-20.

[Jay Cotton]

To this I will add.

The Seead board looks identical to the OSHPark board with the following exceptions.

1.  The finish of the Seead board is a little better.  Looks like its water jet trimmed.

2.  The OSHPark board is much higher quality in all other areas.  They capture the silk screening better

and the platting is really nice.

So, yes the OSHPark board costs more, but the product is better.  If its $3~5 better than Seead, Got me.  

I will stick with OSHPark for now.   

Anyway, I'll bet a large sum that OSHPark sends there boards to China for processing anyway.  Based on 

the turn around time for production.

jc

[J.B. Langston]

As one other data point two of my OSH park boards suffered from the solder mask problem that caused a short between the DTR and GND pins on the serial connector. Probably my fault for running a trace so close to the edge, but Seed did a better job there.  On REV2 I have moved it so it shouldn't be an issue either way.

[J.B. Langston]

I've tagged the REV2 board in github and uploaded the design files OSH Park. For ease of ordering, it's shared here: https://oshpark.com/shared_projects/KdLBtOkh

[J.B. Langston]

Sorry had to make one last-minute tweak... new link is https://oshpark.com/shared_projects/Bn3c0pEt

I added an AVR ISP header for Colin since he didn't want to use a bootloader.

[Colin Little]

Thanks JB for AVR ISP header. Have ordered PCBs from OSH, so look forward to arrival and build !!!

Colin

[J.B. Langston]

Thanks JB for AVR ISP header. Have ordered PCBs from OSH, so look forward to arrival and build !!!

Great, let me know how it goes! 

[J.B. Langston]

Should we update the BOM for the new board.  

Out of curiosity, did you use a KiCad plugin to generate the BOM? I've started researching how to generate BOMS from Kicad and this is something I should really include the official github repo. 

[Rodney Ross]

Jay,

  The board finally got to you!  The SeeedStudio boards(Fusion service) are HASL (with lead) for the inexpensive service.  10 boards up to 100mm x 100mm for $4.90 plus shipping.   You can even choose different colors.    Using the ENIG (gold) like OSH Park moves that up to $29.90 for 10 boards, plus shipping.  I missed the back silk layer when I exported the Gerbers.  Hopefully J.B. will forgive me as that is where he put his name.   It was my fist time with KiCad exporting to Gerber and getting them uploaded.  

  Did you get the new board to work?  Your old board had a baud rate issue, and would not load CP/M.   

[Jay Cotton]

No I have not been able to work on it yet.  I need to order some parts, should be in next week.

[Jay Cotton]

parts came in today.  I'll have a go at building a unit tonight.

jc

[J.B. Langston]

For anyone who might be interested but hasn't been watching the Github repo, I have made a lot of improvements to the debugger and at this time I consider it basically feature complete.  It supports the following:

- Complete disassembly of Z80 instruction set from the AVR monitor (both from memory and in realtime as the Z80 executes them).

- Watch bus activity and instruction execution. Individually configurable ranges for reads, writes, opcode fetches, or all bus activity.

- Break on reads or writes to a specific IO or memory address range, or on execution instructions within an specified address range.

- Single step instructions (or run a specified number of instructions), continue debugging from breakpoint, or run at full speed from the current location.

All of this is done on the AVR and it is completely transparent to the program running on the Z80. Because it is based solely on bus signals, internal state of the Z80 (i.e., register values) is not accessible.

[J.B. Langston]

I've attached an example session that shows the following:

- loading a hello world program from a hex file, 

- dumping the memory, 

- disassembling from memory, 

- enabling breakpoints on IO write and watching bus activity and opcode fetches, 

- debugging up to the break point, 

- single stepping, 

- continuing until the next breakpoint

- disabling watch on bus activity (only opcode fetches remain)

- single stepping again

- continuing again until the next breakpoint

- finally, running the rest of the program at full speed to completion, without any debugging.

[Jay Cotton]

Current status:

Newest code downloaded.  Running on OSH board.

The red board is not working.  Looks like there may be a cold solder joint on the processor socket.  I'll

fix that and retest.

Baud rate issue is still present.  I has got to be something to do with the way I program the part.  Need to look into

the other method of programming.  J.B.  How do you set up programming via the serial cable ?

Still having the memory issues, I think its the z80 board that is at the heart of it.  I can fill ram with any value

from the z80ctrl but running altmon it does not work correctly (kinda points to the z80 board).

I think the problem where I have to fill ram with 0 before running altmon is part of this bug.

No joy booting cp/m (see above).  I suspect its the same bug again.  

planning to do some point to point with the meter and see if I can find the problem that way,

[J.B. Langston]

Baud rate issue is still present.  I has got to be something to do with the way I program the part.  Need to look into

the other method of programming.  J.B.  How do you set up programming via the serial cable ?

I suspect your fuse bits are wrong. You need to make sure you set them up so it's using the external oscillator.  If you're using the internal slow oscillator, your baud rate would be very low since it's based on the AVR clock frequency.

You can install MightyCore bootloader following these instructions: https://github.com/MCUdude/MightyCore#how-to-install. Make sure you select the 20MHz clock and the standard pinout. After it's installed, you don't need to use the Arduino IDE again; you can just run "make install" from the z80ctrl project.

If for some reason you would rather not use the bootloader, you can try looking at the fuse bits it sets and use those. See here: https://github.com/MCUdude/MightyCore/blob/master/avr/boards.txt#L104.  I'd highly recommend using the boot loader though because it makes flashing a lot easier.

 

Still having the memory issues, I think its the z80 board that is at the heart of it.  I can fill ram with any value

from the z80ctrl but running altmon it does not work correctly (kinda points to the z80 board).

Still no clue there... let me know what you find. 

 

No joy booting cp/m (see above).  I suspect its the same bug again.  

If your clock is slow that would also make CPM take FOREVER to boot.

[Jay Cotton]

An update:

I spent a lot of time looking at signals on the bus and the CS bits on the memory card.  I found a small glitch on the CS for the low ram chip.

We are getting a 100ns select when the chip is in fact not selected.  Still digging in on that one.

I used the memory test function of altmon and found that the low 1000h bytes are stuck at 0x7e, The rest of ram looks o.k.

So I see a possible problem with the address lines (maybe).  Remember that the z80ctrl can read/write ram all day with

no problems.  I really suspect the z80 module, maybe I need to get a new board....

I will look at the mightycore stuff and let you know if that fixes the baudrate problem.

[Colin Little]

JB, still awaiting my board from OSH but looking into the programming side. (Not my strong suit!!) As Jay seems to be having a few problems I will follow your instructions per Mightycore link. Out of interest what ISP Programmer do you use? When the bootloader has completed is it the case of then uploading all your files on to the AVR and running Makefile or are there any other steps I need to make. Thanks,

[J.B. Langston]

As Jay seems to be having a few problems I will follow your instructions per Mightycore link.

That's probably your best bet because it makes programming really easy. You can leave the same serial adapter hooked up that you use to connect to the terminal, and avrdude can use that.  If you did want to try without the bootloader, it should be fine as long as you use the right fuse bits but it's not something I tested. Like I told Jay, you should just copy what MightyCore uses.

 

Out of interest what ISP Programmer do you use?

I don't have a stand-alone programmer so I just used an Arduino programmed with the ISP sketch to initially set up the bootloader.  I also have a Bus Pirate that I have used as an ISP before but it's not convenient because it won't provide power to the AVR unless you send it a command separate to turn it on first.

 

When the bootloader has completed is it the case of then uploading all your files on to the AVR and running Makefile or are there any other steps I need to make

You just need to run "make install" and it will take care of uploading everything.  Before you run it, edit the Makefile and make sure it's using the correct serial port for your USB serial adapter.  Also, make sure you have avr-gcc, avr-libc, and avrdude installed so the Makefile can work. On Windows, the easiest way is to put the Arduino IDE's directory containing the command-line tools in your path.  You might also be able to use WinAVR but it's pretty out of date.  Personally, I am using Windows Subsystem for Linux and programming it using the Ubuntu avr-gcc, libc-avr, and avrdude packages. It should work the same if you use a real Linux distro. The only inconvenience with WSL is you have to reset your permissions on the USB device every time you close your Linux shell ("chmod 666 /dev/ttySx").

[J.B. Langston]

z80ctrl now has a page on hackaday.io: https://hackaday.io/project/158338-z80ctrl. Likes appreciated.

[Jay Cotton]

$ make install

avrdude -c arduino -p atmega1284p -P COM6 -b 115200 -U flash:w:z80ctrl.hex

avrdude.exe: stk500_getsync(): not in sync: resp=0x30

avrdude.exe done.  Thank you.

make: *** [Makefile:24: install] Error 1

Any ideas ?  This is FTDI cable to SIO port 0 on board.  COM6 is the correct port name.  

the .1uf cap is installed.  

If I say help to a console session is says syntax error back.  So I think its listening on the port.

[J.B. Langston]

You may be running into the problem I had with the DTR line being shorted to ground. Check if there is continuity between the pins. If so you need to cut the DTR trace on either side of the GND pin and then run a bodge wire from the DTR pin to the bottom pin of C7.

If this is the problem, you can also work around it by holding down the reset button and releasing it immediately after you run make install.  However, I don't recommend running like this for very long (although I did for some time) because it's probably hard on your serial adapter.

I think I caused a manufacturing defect by running the DTR trace between the Serial 1 pin holes and the edge of the board. There was not really enough space to comfortably do this and it turns out the solder mask for the ground pin did not cover the DTR trace, so when I soldered it, I created a solder bridge between the two.  I verified this on the first OSH park board I built as well as the third unbuilt board, but it is not the case on the second one that I partially built.  I think the tolerance is close enough that it could vary from board to board.  This doesn't seem to affect any of the boards you sent me; in fact the solder mask tolerances on those boards seem better than the ones from OSH park in general. I have fixed the routing of the DTR line in the REV2 board.

[Jay Cotton]

should add that I had to use the eprom programmer to get the boot loader onto the chip.  I used 
MightyCore/avr/bootloaders/optiboot_flash/atmega1284p/optiboot_flash_atmega1284p_UART0_115200_18432000L.hex

Not certain that was the correct choice.

[J.B. Langston]

The number at the end is the speed in Hz. You need the 20MHz version: https://github.com/MCUdude/MightyCore/blob/master/avr/bootloaders/optiboot_flash/atmega1284p/optiboot_flash_atmega1284p_UART0_115200_20000000L.hex

You also need to make sure you get the fuses set the same way MightyCore does, using the link I sent earlier. 

[Jay Cotton]

Got the red board running.... can see the SD card.  Need to do more testing.

cold solder joint.

[J.B. Langston]

Great! Serial is running at the right speed now?

[Rodney Ross]

Great News,  Hopefully you can figure out what it was on the "purple" board.   But at least you have one running.    I've got to get JB;s updates and compile and load them.   Runs CPM 2 great.    Now to figure out how to run the SIMH version of CPM/3 (says it uses banking) I've started to look at what it would take, but need 3 banks (or more) but not sure what port / format they use to bank the memory..   Can we adapt one of the ROMWBW boards with their MMU?  I'll keep reading,     I did switch over from my FTDI serial to Marco's Propeller based VT100 card,   Plug it in and it works..  But some of the software is not configured for VT100 yet...     

[Jay Cotton]

Status as of now.   Both boards.

Can't make install.  I installed the boot loader, no joy.  I ordered a MightyCore board, may be here next week.

Baud rate is stuck at 5602.  This is a non problem until the Mightycore  shows up.

Memory below  0x1000 is stuck at 0x7e, when viewed from altmon.  This has got to be a ram problem.  

I am tracking that down now, I suspect an OR gate is not or'ing.

Almost there, should have 2 running boards next week.  I'll update when I find this ram address problem.

AS a side note.  I attempted to run RomWBW with the z80ctrl board.  No joy, looks like there may be problems with the

device handling, or the baud rate or what ever.  Lets wait on that until memory and MightyCore.

Ah yes, the propeller vt100 is cool, but I still need to use xmodem and have not done the leg work to make SIO-1 work with xmodem.....  

[J.B. Langston]

Can we adapt one of the ROMWBW boards with their MMU?

That might be possible, but it should also be possible with just a standard 64K RAM board.  We just need to add an IORQ handler that listens on the right port, and when a different bank is requested, it can swap it in from  the SD card.  It might be a little slow; that remains to be seen.

[J.B. Langston]

Did you double check that you have the fuse bits set correctly?  0xf7 for low and 0xd6 for high, I believe.

Also did you ever change to using the 20MHz bootloader? The one you were trying to use at first was for an 18MHz clock.