Mooplog - Retrochallenge

RetroChallenge 2016/10 - One bodge to fix them all

2016-11-02T21:35:00+00:00

It's two days past the deadline, but I found an extra moment to work on my SD card interface today and I have it working!

I switched the clock output to the SD card from SH_CLK to /SH_CLK to move the rising edge of the clock to a point where the output from the shift register is stable, and now it works nicely.

This eliminated the critical timing that the Bus Pirate was have gotten away with but my circuit did not.

Once I had this working I checked that the 74HCT595 was clocking the data coming back from the SD correctly. Since my test program soft resets the rc2014 when it finishes I was able to check this from BASIC.

Now that this is working I need to write a (less messy) program to fully initialise the SD card and switch to fast mode. Once that is done I will verify the schematic by rebuilding the circuit on stripboard from the schematic, before designing a proper PCB for the circuit including a proper SD card socket.

There are also a couple of potential minor hardware improvements to investigate:

As noted in my last post that it's likely that I can get rid of the second 74HCT374 and switch to just using the simple edge trigger circuit.
Fast mode should be pretty optimal when used with the Z80 OTIR instruction to write many bytes of data from memory straight to an IO port, however for reading data from the card I currently need to alternate writing 0xff and then read the result back with with an IN instruction. I can use the INI instruction to automatically keep track of where the read bytes should go in memory but I can't use the INIR instruction which would be faster. Some extra logic to (optionally) trigger a write after a read would allow me to use INIR to read blocks of data with the implicit write priming the input shift register with the next byte after each read.

Finally, here's the final schematic:

Even though I didn't quite get it done within the deadline I can call this RetroChallenge a success (it was definitely good motivation).

For bonus points I managed to use exactly all the gates in the 7400 quad NAND and 7404 hex inverter that make up my glue logic.

Now it's probably time to start reading the CP/M BIOS Alteration Guide!

Retrochallenge 2016/10 - Tools

2016-11-01T20:00:00+00:00

During Retro Challenge I needed a way to run machine code on my rc2014, as BASIC was incapable of the performance needed to initialise the SD card in bitbang mode.

I didn't (and still don't) have an EEPROM burner when I first got my rc2014, and although the version of BASIC in the stock rc2014 ROM does support the USR() function it appears to jump to a hardcoded address within the ROM so this didn't help me much.

I ended up finding the assembly language source of the BASIC interpreter (or one very similar) and noticed that the address the USR() function jumps to is not looked up directly from the ROM, but copied to a block of information kept in RAM. Once I knew the address of that block I was able to modify it so USR(0) would jump to an arbitrary address.

With this method I was able to poke in arbitrary code and execute it, but this was far from an ideal workflow.

To improve this I wrote some Python scripts which would output the BASIC code to load a binary image into the RC2014's memory at a given address or run code from a given address. Once appropriate delays were added to avoid overflowing the (1 byte) input buffer on the RC2014's serial port I was able to combine these scripts with z80asm and a makefile to make a nice toolchain for rapidly deploying and testing programs to the RC2014.

By writing the program such that the RC2014 jumps back to the reset vector at address 0x0000 programs can be developed without the need to constantly reset the RC2014 (unless something goes wrong in the program).

I set up my Makefile with additional commands to output hex dumps of the program, annotated assembly, or to run a program that is already resident in memory.

The only issue I've encountered with this system so far is that it is quite slow to load large programs. For my Retro Challenge project the load time was so long that I had to wait for it to finish before reissuing the run command. The automatically sent run program was lost because the loader was still running.

This could be improved by writing a faster loader in assembly which could be bootstrapped with a very small BASIC program. If I had an EEPROM burner a replacement boot ROM could be made which would boot straight into the fast version of the monitor program.

The scripts and Makefile I used are on my GitHub under the RC2014 Tools project. They will work on a Linux system or similar, or on Windows with some modifications.

Retrochallenge 2016/10 - Deadline

2016-10-31T23:08:00+00:00

I'm at my deadline for RetroChallenge 2016/10 and unfortunately I'm tantalisingly close to having something that works, but not quite there.

I have the bitbang/slow mode working and generating pulses that match the output I get from my Bus Pirate when using it to talk to the SD card. However, the Bus Pirate gets a response and my circuit does not.

I blamed my level shifter for a while. As an experiment I tried writing to the card from the Bus Pirate and reading the response through the level shifter works fine, so that can't be the problem.

Bitbang mode was fixed by adding an additional edge trigger circuit. Instead of a synchronous edge trigger I used the simple trick of feeding a signal and an inverted copy of the signal into an AND gate. When the signal goes high the inverted version remains high for the propogation delay of the NOT gate used to invert it, so the output from the AND gate is temporarily high. Since I had a free NAND gate and second free NOT I used these to build an AND. I ended up picking the existing EDGE signal (ie. the synchronous edge trigger) as the input to the new edge trigger. This provided a signal that could be used to make the output flip flop's latch transparent for only a brief period.

I could probably at this point do away with the synchronous edge trigger and save a mostly unused 74HCT374, but there was no time to test this today. I will test this when I get chance.

With the bitbang mode working I was able to attempt to initialise the SD card at the low clock rate it requires. After some fiddling I discovered that my output pulse train was off by one relative to the clock pulse. In an effort to get things to work I bodged the values I was writing to make the output signal match what I see when using the Bus Pirate. This included adding a new bit to the CONFIG register to drive the serial input on the output shift register. This ensured the Data Out line (MOSI) to the SD card was pulled high, in order to match exactly the Bus Pirate's behaviour.

It was difficult to get a screenshot that captured the whole pulse train, but the above shot shows the Bus Pirate sending CMD0 (0x40, 0x00, 0x00, 0x00, 0x00, 0x95) and receiving 0xFF (no response) followed by 0x01 (OK). The shot below shows the commands sent to the Bus Pirate and the response.

The next shot shows my circuit sending the same output, but recieving no response.

In both cases a large number of clock pulses were sent with the SD card's chip select deasserted, as is apparently required to initialise the card.

My suspicion is that either my timing is too fast - I'm currently running at 330kHz while the Bus Pirate is running at 33kHz - or the rising edge of my clock is very subtly off with respect to the data.

There are still hardware bugs (the off by one issue, mainly), but the final schematic and final netlist are included below for posterity.

I plan to continue working on this project after RetroChallenge and will and post further updates as I figure it out.

I also plan to write a post about the toolchain I have setup for running assembly programs quickly and painlessly on the RC2014. Hopefully I'll be able to post that tomorrow.

Retrochallenge 2016/10 - State of Play

2016-10-31T17:11:00+00:00

As it stands my RetroChallenge entry is close to working, but not quite there.

The fast mode appears to work and I was able to decode the SPI packets sent to the SD card with OpenLogicSniffer's SPI analyser module.

The picture above shows the signals and the decoded data for the SD card CMD0 (Software Reset) message which is the first step in initialising the card. The message is the 6 byte string 0x40 0x00 0x00 0x00 0x00 0x95 where 0x40 is the command (bit 6 is always set), the four 0x00s are the empty parameter section, and 0x95 is the checksum for this command. More information on the SD card SPI protocol is available on this page, which I've been referring to regularly for this project.

The eagle eyed will notice that this capture shows an 8mHz clock and therefore the device is running in fast mode. For the SD to initialise correctly it needs to be initially clocked slowly (100-400kHz).

Unfortunately, the slow mode, which I was expecting to be the easy bit is currently not working due to a hack I used to get fast mode working.

The current schematic, seen above, shows that the 'Shift /Load' input of the output data shift register (U3 pin 1) is driven by the SHIFTING net. This gave the correct timings to load the register when data was written, as the register's input latch would be transparent while SHIFTING was low. SHIFTING goes high while the autoshift register (U7) is outputting a 1, so the last value seen by U3 is latched in just before the train of clock pulses is generated.

This breaks slow mode because SHIFTING is always low when /BITBANG is asserted, so the output from U3 is always a copy of whatever is on bit 7 of the data bus.

This should be fixable if I can find a better way to load this register before time runs out.

Retrochallenge 2016/10 - Due diligence

2016-10-30T22:45:00+00:00

To avoid the work done designing my SD interface being wasted I decided to verify the concept before going any further.

I used my Bus Pirate to verify that the SD card I have would respond to the commands I expected using the protocol I expected.

The Bus Pirate supports many bus protocols including the SPI bus that the SD card supports in the mode I'm using.

I don't have an SD card breakout board so I ended up buying a micro SD card with a standard SD adapter and soldering some right angle pin headers to the pads. This gave me an SD adapter that would plug into a breadboard.

I initially used the Bus Pirate's probe cable as a quick way to connect to this adapter, but this got frustrating as the mini grabbers had a habit of letting go at inconvenient times. To get around this I made a quick adapter on some stripboard.

This little adapter also makes it easy to remove the SD adapter from the Bus Pirate without having to look up the pinout again. It should come in handy on future SD card related projects and maybe for writing raw data to the SD card.

Unfortunately I don't have any logs of the session, but with this adapter and the Bus Pirate I was able to initialise the SD card and read blocks of data. This gave me confidence that my project would work and would be worthwhile.

Retrochallenge 2016/10 - Building retro computers with modern tools

2016-10-23T20:26:00+01:00

I've been struggling for free time this month for poking around with breadboards and other fun things. To work around this, and still (hopefully) get my RetroChallenge entry done, I decided to use a simulator so I could work on it with my laptop whenever and wherever there was time.

For an earlier RC2014 project I used LogiSim which is simple and easy to use, but I quickly hit some limitations. The built in sequential building blocks (shift registers, latches, etc) appear to support only a limited set of variants. There is no option for asynchronous resets, or transparent latches on the shift registers. It includes combinatorial building blocks (logic gates, etc) also, but these do not appear to work correctly for building sequential circuits, as feedback is not always handled correctly. Because of this I was not able to simulate the exact characteristics for most of the 74 series ICs I was using.

To solve this problem I switched to using Altera Quartus to build a model of the circuit and ModelSim Altera Edition to simulate it. I mainly chose this because I've used it previously for FPGA projects, and because if some functionality is missing I can implement it in Verilog.

When redesigning the autoshifter circuit (to shift out 8 bits of data after each IO write) I built it as a Block Diagram/Schematic File (.bdf) in Quartus. This allows the design to be entered as a schematic with various logic symbols supported by default. Additional components can be created with a hardware definition language such as Verilog, or by using Quartus' "MegaWizard Plug In Manager" to configure and insert a variant of an IP core. I set my project up for the Cyclone II FPGA as I have used it for previous projects. To simulate the 74HCT165 shift register I configured a variant of the LPM_SHIFTREG IP core with 8 bits of data, parallel inputs and serial inputs, serial output, and a clock enable pin.

Unfortunately this still does not quite match the 74HCT165 exactly as it has D flip flops rather than transparent latches. I could build my own shift register in Verilog, but to save time I opted to stick with the LPM_SHIFTREG version and ensure that the timings seen in simulation were such that the transparent latches wouldn't cause a problem.

In order to test the design I set Quartus up to launch ModelSim and run Gate Level Simulation after compilation. ModelSim can be driven manually through the GUI, but this is fairly fiddly and repetitive. Fortunately it supports scripting via 'do files' which contain lists of commands for ModelSim to interpret.

I set up four do files:

init.do - Reset, add graphs for appropriate signals, set default values for inputs
shift8.do - Drive the data bus to the appropriate values to set SHIFT8 and deassert /BITBANG, then assert and deassert /CONFIGWR
write.do - Simulate a write to the device by driving the data bus and /DATAWR signals, zoom graph to fit
sdtest.do - Run the previous three do files in sequence, zoom graph to fit

This allowed a fairly quick turnaround by hitting compile in Quartus, selecting the project once ModelSim launches, then typing 'do sdtest.do' to run the simulation.

For a different project I could have sped things up by keeping everything inside ModelSim, but this would have required me to design the circuit in a hardware definition language. Since my final target is a circuit built from discrete components and not an FPGA bitstream I decided to take advantage of the Block Diagram/Schematic feature in Quartus. This way everything could be easily translated back to a physical circuit once it was verified as working.

Now I have the autoshift circuit working, theoretically, I just need to find some time to build and test the physical version!

Retrochallenge 2016/10 - Previous version and problems

2016-10-15T13:51:00+01:00

In my previous post I promised to show the previous implementation of my Z80 SD interface, and to run through the problems which I intend to fix this month.

The 74138 (U1) in the top left of the schematic is used to detect and decode IO reads and writes from the Z80. Three bits of the address bus (A7, A1, A0) are decoded along with the /RD line, M1 line and /IORQ line. With this configuration the device responds to any IO address between 0x80 and 0xff. Some more gates will be used to further decode the address later. The lower two bits (ie. the address modulo 4) select a register within the device. Address 0 selects the DATA shift register (U4) for reads or writes while address 1 selects the CONFIG register (U3) for writes only.

One NAND gate from the 7400 (U2A) quad NAND is used to invert the CONFIGWR signal, as the 74138 outputs are active low while the latch input on the 74374 is active high.

In the middle row of the schematic are the 74374 register (U3) that holds configuration information and the 74299 shift register (U4) that is used to transfer data to the SD card. To the right of these is a 74165 (U7) shift register that implements the automatic shifting mechanism for high speed mode along with some more NAND logic (U2B, U2C, U2D) to generate the appropriate signals depending on the operating mode.

The automatic shifting behaviour is implemented by latching the state of the SHIFT8 bit of the config register into all 8 bits of U7's input register when /DATAWR is asserted (ie. the data register is written to). This fills the register with 1s. The serial in (Ds) pin of the register is connected to ground so with each clock pulse the train of 1s is shifted and the gap is filled with a 0. The serial output of the register (SHIFTING) is NANDed with the clock by U2B. The output from U2B is either a train of 8 inverted clock pulses or a constant logic 1 level, depending on the state of SHIFT8 at the time the DATA register was written to. NAND gate U2C will either invert this train of clock pulses if /BITBANG is high, or reflect the inverted state of the /BITBANG config bit if U2A is outputting a constant logic 1 at the time. Put together this allows either the SHIFT8 config bit or the /BITBANG config bit to control the clock depending on the desired operating mode (relying on the driver to avoid trying to do both simultaneously).

The final NAND gate of the 7400 (U2D) is used to invert the /DATAWR signal to drive U4's S1 input to select the Parallel Load operation when /DATAWR is asserted or to Shift Left otherwise. S0 of U4 is tied to ground as the Shift Right and Hold operations are never used.

Finally, a 74107 dual JK flip flop was used to divide the RC2014's clock signal (CLK) by four to produce (Q_CLK). This was initially intended to solve a timing issue, but has caused more trouble than it was worth.

The timing diagram below shows the behaviour of the device when the SHIFT8 bit is set and a write is issued to the DATA address.

A couple of issues are noticeable:

SH_CLK is producing one partial pulse, followed by a gap, followed by 7 real clock pulses.
/DATAWR (and therefore SH_LOAD) is asserted for several clock pulses.
CLK (actually Q_CLK) behaves strangely.

Most of these issues were introduced by attempts to work around other problems.

Before the clock divider was introduced U7 was emitting a train of 11 clock pulses rather than the expected 8. This is because the 74165 has a transparent latch rather than an edge triggered latch. The Z80 asserts /IORQ for many clock cycles so the train of 1s from SHIFT8 was being reloaded, wiping out the 0 introduced through the Ds input, until /IORQ was deasserted. Introducing and resetting the clock divider was an attempt to prevent the shift registers from being clocked during this period by holding it in the reset state when /DATAWR is asserted.

Unfortunately because the Z80 instructions take a variable number of clock cycles to complete and aren't necessarily a multiple of 4 cycles the state of the divided clock when /DATAWR is asserted is not predictable. This is likely the cause of the glitchy short pulse seen on CLK as /DATAWR is asserted.

Without this unexpected pulse U4 would not be loaded, as 74299's the Parallel Load operation is synchronous with the clock, and shares a clock with the Shift operation. Extra logic would be required to create a seperate clock that is a superset of the shift clock.

Given these problems I'm going back to the drawing board slightly. I may try adding the extra logic to clock only the 74299 but if that fails I'm replacing the 74299 with a pair of shift registers - a 74165 for data moving from the Z80 to the SD card and a 74595 for data moving from the SD card to the Z80. This is probably wise anyway as the 74299 is a rare part which is many times the cost of a 74165 or 74595 and supplies are less plentiful.

I'll also be removing the 74107 clock divider circuit and replacing it with a simple edge trigger circuit to limit the /DATAWR pulse to a single clock.

Hopefully I will have a write up of this new version soon.

Retrochallenge 2016/10

2016-10-05T20:04:00+01:00

I decided to join in with ` <http://www.wickensonline.co.uk/retrochallenge-2012sc/>`__Retrochallenge 2016/10 this October. I'm also hoping this will provide some incentive to write more posts and updates about other projects once I'm back into the swing of things!

My goal for this Retrochallenge is to finish an SD card interface I started designing for Spencer Owen's ` <http://rc2014.co.uk/>`__RC2014 Z80 based computer (which was spawned by a previous Retrochallenge, hence the name). This should work with most Z80 computers that don't do anything crazy to the I/O interface, so I may also get it working on a ZX Spectrum if there is time.

I'm intending to build my SD interface from 74 series and similar discrete logic ICs. This is partly for fun and partly because the microcontroller in the SD card is likely already more powerful than the RC2014. Adding another microcontroller into the mix to interface with the one in the SD card is just a step too far.

I'll be using the SPI-like mode of the SD card protocol, not least because information on the faster SD mode is not publicly available. The SPI-like interface should allow me to use shift registers for communication with the SD card.

I was initially planning to use a 74ALS299 universal shift register to reduce chip count. Unfortunately, in addition to being somewhat hard to get, the interface on this chip is troublesome as the shift, shift direction, and output enable are all synchronous and controlled via two pins that set the operation. The extra glue logic needed to deal with this completely nullifies the benefit of using a single universal shift register. Because of this I'm planning to redesign around a pair of shift registers: a 75HCT595 serial-in-parallel-out register and a 75HTC165 parallel-in-serial-out register.

The SD card requires a slow clock pulse for initialisation (around 100khz), but once initialised supports faster clock speeds. The design is complicated by the need to run at both speeds, but I have a scheme to cope with this.

My intended interface uses a pair of registers mapped to the Z80's I/O space.

DATA

Writes to this address latch the byte from the Z80 data bus into the 74HTC165 which is used to send data to the SD card.
Reads from this address enable the outputs on the 74HTC595 shift register which receives data from the SD card.

CONFIG

Writes to this address update a 74HTC374 register holding a configuration byte. The following bits are currently used:

autoshift - Automatically shift 8 bits from the shift registers to the SD card and back after a write to the DATA address. This is used for the SD card's "normal" high speed mode and should allow fast enough I/O that the Z80 becomes the bottleneck.
clock - OR'd with the automatic clock signal to the shift registers and SD card, allowing communication at a speed controlled directly by the Z80 to provide a 'bitbang' mode. This mode is not efficient, but allows the slower speed required for the SD card initialisation process without much extra logic.

An initial version similar to this design has been built on a breadboard using a 74ALS299. In addition to the issues with the synchronous control signals needed to load this shift register, there were also compatibility issues with the timing of the Z80's I/O control signals. This requires additional glue logic and a redesign of automatic shifting logic that enables the high speed mode to work.

Before I take the previous version apart to rebuild, I'll take some logic analyser captures indicating the timing issues, and write up (and remind myself of) the problems.