h8-64k-dram

[smb...@gmail.com]

When Glenn sold me one of his H8s, he asked me what the first board I was going to design was, and I told him I'd do something totally pointless but mildly nostalgic, like a modern DRAM memory board. Well, it didn't make it to my "first" design, but here it is. A combination 64K DRAM and ORG0 board.

The board uses the Intel D8203-1 DRAM controller. This controller handles DRAM timing and refresh, and will automatically insert refreshes if they are not called for externally. The internal (aka "failsafe") refresh necessitates wait states, because the DRAM controller could be in the middle of a refresh cycle when you command it to do a read or write, and the read/write will have to wait until the refresh is completed.

This is almost working with my H8-8085 CPU board. By "almost", I mean it passes the memory test in the 32K ROM. However, the H17 will not function with it. I suspect the unpredictable wait states are throwing off the delicate timing of the H17 code.

It fails miserably with the original Heathkit 8080 board and Norberto's Z80 board. This was a surprise. I figured if it worked on the 8085, it would work on the 8080 and Z80. However, there appears to be differences in when READY/WAIT are sampled and how the WAIT cycle is implemented. I think this particularly impacts writes.

The next logical step would be to see if the internal/failsafe refreshes could be eliminated in favor of externally-commanded refresh. Possibly try using the Z80's refresh pin to trigger this. With external refresh, there should be no need for the unpredictable wait states. Trionyx did implement a DRAM board, and it does have some detailed diagrams on how they performed the refresh timing.

Anyhow, not sure I'm going to continue this, but I will get the schematic up. It was a fun diversion, but I'm not sure it's worth investing time when SRAM is the sane preferable choice. It's a pity as the next step would have been to switch to 32 4116 ICs.

Scott

[norberto.collado koyado.com]

I’m done with DRAM that are not connected directly to the Z80 CPU as in the H89. Going over the H8 external bus to the DRAM board, it is not an easy task. The timing has to be correct.

 

I’m happy with the static RAM…😊

 

More information here:

 

https://sebhc.github.io/sebhc/documentation/supplemental/norberto_6mhz_h8.pdf

 

Norberto

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/3264e60b-de87-41b7-9aac-f71f4bdf6356n%40googlegroups.com.

[Peter Higgins]

Scott - I've got to commend you for even trying this!

One of the first implementations of the Intel DRAM controller chip I had experience with was on an S100 bus 64K DRAM board manufactured in the early 80's by a small company called Netronics. It used the Intel 8202 - same as 8203, but limited to 16K DRAM chips. I must have spent the better part of a year trying to tweak it to work in an 8080 system and my experience paralleled yours. I subsequently learned that most owners of this Netronics DRAM board had been far less patient that I was, and quickly trashed them.

[smb...@gmail.com]

The D8203 datasheet made it seem so easy, too! 

Unfortunately, I think there are at least a few points where the datasheet is inaccurate, or at the very least misleading. For example, it's implied that you can drive READY with XACK to implement waitstates. But what the datasheet doesn't mention is that apparently XACK can come well after a RD or WR cycle has been completed by the CPU, if the 8203 is busy executing a refresh. This causes both lost writes and lost reads. I was able to compensate for that particular problem (at least with 8085) by pulling down READY at the start of the RD or WR cycle and holding it until the XACK eventually arrives, but that's contrary to what is shown on the datasheet.

Oh well, maybe if I get adventurous I'll try a different DRAM controller.

scott

[smb...@gmail.com]

For whatever reason I can't seem to let this one go. I'm considering taking another stab at the DRAM board. Did a little bit of research:

First, there's documentation on a Trionyx memory board at https://github.com/sebhc/sebhc/blob/master/documentation/hardware/Trionyx/Trionyx%20Memory%20Board.pdf. It does not use the D8203 chip that I tried to use, but it does have a diagram of timings showing that they placed refresh 900ns after the start of the memory cycle. This is timed with various 74LS123 ICs, using resistor/capacitor to generate timing in various ranges (200ns here, 400ns there; lots of timings associated with DRAM). I want to stick with the D8203 design though, I don't want to try to reproduce the trionyx board with timing manually implemented using a half-dozen or more 74LS123.

Second, there's the D8203 board that was recently on eBay. I didn't win it, but I did save all of the pictures from the listing. There's a good shot of the back of the board that I can use. Pictures of the front of the board are not nearly as easy to resolve traces, but I might be able to derive something of the function by mapping out what I'm able to. There is what seems to be a timing circuit in one spot, note the one ceramic capacitor that is not a bypass cap. Unfortunately, that IC is also the only unreadable IC in all of the pictures in the eBay listing. It doesn't seem to be a 74LS123, but must be some other timing IC. Maybe someone whose eyes are better at pulling signal out of the noise can see what IC it is. This wouldn't be the first time I've tried to reverse engineer a board with nothing more than an eBay listing to go off of.

So what I'm thinking I'll do is to add a few 74LS123 timing circuits to my DRAM board. I'll connect them to a PLD, so I can easily try out different strategies without having to rewire. My first goal will be to insert the refresh 900ns after the memory read/write starts, just like the Trionyx board does. Failing that, I can try other strategies with trying to time the refresh. I think the key is going to be to make sure that wait states are not generated, as wait states will break the H17 timing constants (that's my running assumption, at least). My solution might only work for a single CPU speed, as the timings may change when CPU speed changes.

A couple pictures of the eBay board are attached.

Am I nuts for pursuing this, or does it seem doable?

Scott

[Peter Higgins]

I'd say "nuts for pursuing this" :)

I have a Trionyx 64K DRAM board. It was flaky as originally shipped. Trionyx wrote up a series of release notes with detailed mods to allegedly improve performance and reliability. If anything, I found these mods just made the board even more flaky. I was very happy the day I replaced that highly complex and unreliable board with a super-simple ultra-reliable single SRAM chip memory board.

[Glenn Roberts]

Well you could always try and talk down the guy that wants $2,500 for his H8. That’s got the same RAM board in it 😀

Sent from my iPad

On Mar 8, 2023, at 9:32 PM, smb...@gmail.com <smb...@gmail.com> wrote:

For whatever reason I can't seem to let this one go. I'm considering taking another stab at the DRAM board. Did a little bit of research:

--

You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fefe2ec3-c62a-4db6-96c8-b6b411dfa098n%40googlegroups.com.

<dramboard6.jpg>

<dramboard1.jpg>

[Scott Baker]

Glenn, I offered him something around $400 back before I bought your H8. He countered at $1700. I told him we had irreconcilable differences.

It's been around 4 months. Maybe I should try him again at $500.

Peter, I know I'm nuts. :) But I also get stubborn and sometimes refuse to let something get the best of me.

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/469DCE46-D2D2-474C-AABC-46055344FBC8%40gmail.com.

[smb...@gmail.com]

I made my second iteration on the DRAM board, and I still don't have it right. What I learned is:

* Noise pulses on the H8 bus will glitch the DRAM board. Occasionally I will see a very short spike on MEMR at the same time my 8085 board releases the address bus. This causes me to initiate a DRAM read simultaneously as I'm dropping the CS to the DRAM controller, and my logic thinks I'm waiting for a DRAM read but the DRAM controller did not queue the operation. I'm going to put Schmitt Triggers and RC filters on the MEMR and MEMW pins. With this fix, the DRAM board might actually work with the 8085.

* On the Z80 and 8080 boards, if the DRAM-controller has initiated a refresh at the same time a write occurs, then the refresh can take so long that the Z80 or 8080 will conclude the write cycle before the DRAM controller has had a chance to pick it up.  The Z80 and 8080 do not extend a write cycle when a wait is inserted. They check for waits before starting the memory cycle. Revision 3 of the DRAM board will resolve this by latching the address and data during a write, and holding the CS to the DRAM controller until it has had a chance to pick up the request, while holding a wait state.

The one thing I haven't tried yet is timing the refreshes so we don't need to inject wait states. That may be easy with a Z80 since it has a Refresh output, but not an 8080 or 8085. I could even try a scheme that does away with all this dynamic wait state generation, and just statically extends all memory cycles to accommodate both the memory cycle and a refresh.

Scott

[Douglas Miller]

Just another hare-brained idea... The DRAM board could implement something similar to the Z80 refresh controller, and time those refreshes to M1 (just like the Z80 - it only refreshes in M1 cycles). Probably lots of ways that could run afoul, though.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b067d202-aacc-482e-85c6-fff1ac30ce99n%40googlegroups.com.

[smb...@gmail.com]

That's one of the suggestions in the data sheet, though I did not have success with that approach. I also (last month) tried timing it to the Z80 Refresh pin and ran into some unexpected problems and abandoned the approach. I'd really like a solution that's portable across Z80 and 8080.

One of the issues with using M1 is that I believe it's only asserted for the first byte of a multi-byte instruction. Z80 solves that by having the dedicated refresh pin.

Scott

[Douglas Miller]

Z80 asserts M1 for each opcode fetch, but not for (plain) memory or I/O access cycles. The Z80 does a refresh cycle in every M1 cycle. Z80 instructions with multiple opcode bytes have multiple refresh cycles.

But, it sounds like it's not a viable approach.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fe30d994-0ec6-4b3b-9b46-c2b848f4c1e5n%40googlegroups.com.

[norberto.collado koyado.com]

Can you share your schematics and which DRAM controller are you using?

 

Norberto

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of smb...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/b067d202-aacc-482e-85c6-fff1ac30ce99n%40googlegroups.com.

[norberto.collado koyado.com]

Just checking the specs on the D8202A controller, hopefully you are latching the data going into the H8 bus, with the /XACK signal during a read cycle. Also, use the /XACK signal to control the CPU READY pin.

 

NOR gate MEMR and MEMW on H8 bus to drive /PCS. Then use /PCS to enable the RD/WR to the DRAM and it must be latched. Use the /02 clock to clear the latch once they de-assert.

 

I’m not sure if you are using a data buffer or not. If using a buffer such as 74LS240/540 or 74LS640, then you will need to keep the buffer “on” as MEMR/MEMW signals de-asserts. Otherwise you have a race condition between MEMR/MEMW signals and the data buffer turning off simultaneously.

 

The questions are:

1. How are you driving pin 25? To +12V in series with a 1K resistor; correct?
2. How are you driving pin 34 (refresh request)? It should be grounded for advanced read. You want internal refresh and avoid external refresh.
3. On clock you are using the H8 bus /O2 2MHz; correct?

Can you share your schematics to provide more feedback?

 

At DEC I saw the 8085A directly wired to DRAM and no need to use the Intel DRAM controller. The way they refreshed the RAM was to interrupt the 8085A every 2ms with a 555 timer to do this refresh operations. I think this is the best option, but requires changes to the monitors.

 

Norberto

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of smb...@gmail.com
Sent: Saturday, March 18, 2023 11:22 AM
To: SEBHC <se...@googlegroups.com>
Subject: Re: [sebhc] Re: h8-64k-dram

 

That's one of the suggestions in the data sheet, though I did not have success with that approach. I also (last month) tried timing it to the Z80 Refresh pin and ran into some unexpected problems and abandoned the approach. I'd really like a solution that's portable across Z80 and 8080.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fe30d994-0ec6-4b3b-9b46-c2b848f4c1e5n%40googlegroups.com.

[smb...@gmail.com]

I'm using D8203. Note that there are several things that are not obvious in the datasheet, and may not work as expected. For example when fallback timing is used, !XACK can occur well after a host memory read or write cycle would normally have concluded, if the DRAM controller is busy servicing a refresh. Logic analyzer shows it may not even queue the request if it's in the middle of a refresh. Also, it will not release !XACK until after !RD or !WR has deasserted. Any of these precludes the simple use of !XACK to generate wait states as shown in the datasheet. It just gets more and more complicated the deeper you dig into it.

I'll work on getting the schematic and PLD equations out for the DRAM board this weekend. I have to warn you, though that it's grown to be very complicated as the board is designed with signals routed through PLDs and jumpers so that rework can happen without needing an xacto knife and a soldering iron.

Scott

[smb...@gmail.com]

Whoops, my previous message has been sitting in the buffer. Just sent it, and let me answer your questions below:

Yes, the data is latched as per the data sheet. On the 8085 board, it's good enough to occasionally boot into HDOS. !XACK driving wait is not sufficient, as I mention in the previous message. I can see it on the scope, XACK can and will occur after the 8080 read or write cycle has completed. It can show up too late to wait; the CPU has already read the data from the bus and moved on.

I'm driving PCS from the address bits, similar to how the 8080 64K RAM board works, so I can selectively enable 8K banks. It's much easier to test using the the 8080 54K RAM board to provide 48K and the DRAM board to only provide 8K (with an empty 8K between the two).  I don't use MEMR or MEMW to gate CS, since they're already being used to generate RD and WR.

I'm running the CPU in 64K mode, and thus pin 25 operates as AL7, not as OP1 or B1. Pin 34 has a pull-down, unless I want to initiate an external refresh (i.e. from the Z80 Refresh pin or from M1+SACK as described in the datasheet). Why are you suggesting 'advanced read' mode? That would require S1 and ALE, neither of which we have on the H8 bus, and it would require 16K instead of 64K DRAM. Normal mode seems much less complicated.

I'm running the clock at 20 MHz. Data sheet specifies a clock period of 40-54ns. I don't see how we could use the H8 clock, as it would be approximately 500ns. 20 MHz I found to be too fast for the H8 bus, the 8203 will attempt to complete a write cycle in approximately half of a Z80 write cycle, and the data won't even be on the bus. I slowed it down to 10 MHz, though that too is out of spec per the datasheet. Also, there's no need to sync it to the H8 clock, datasheet says in a note, "ALE, !RD, !WR, and REFRQ inputs do not have to be externally synchronized to the 8203 clock".

I agree there's lots of other ways to do this, including the Trionyx board which we have documentation and schematics and timing for, but this controller seemed like a good drop-in replacement for an SRAM board.

This ought to be clearer once I've posted schematics.

Scott

[norberto.collado koyado.com]

Thank you for the feedback. I still have the scars from the 80’s when dealing with Dynamic RAM boards for the H8 system. That pushed me to design my own board using static RAM back then.

 

Hopefully you will figured out. I will continue working on the Z67-SDC controller to get it working as II want.

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/cc071c61-5bf1-4501-8724-54c4a63a294an%40googlegroups.com.

[smb...@gmail.com]

The schematics and PLDs for the DRAM board are at https://github.com/sbelectronics/h8/tree/master/h8-dram.  Unfortunately it's a little hard to follow, as today's experiment had some manual wiring associated with it. v0.9 is the one I have now. v0.14 is my work-in-progress for the next respin.

I think I might nail it with the next revision (said that last time, I did). If nothing else, I've thrown everything but the kitchen sink onto the board.

DRAM board is an epic pain in the butt, and multiple times I've asked myself why I'm still doing this. I'm taking it as somewhat of a personal challenge. This has turned into one of the most difficult hardware design tasks that I've tackled (technically I'm a software engineer, not a hardware engineer!). DRAM is just finnicky, and there's a million tricky things that can go wrong, some of them deterministic and reproducible, some pretty close to random.

Scott

[Steven Feinsmith]

I earned experience with static and dynamic memory in the late 1970s
and early 1980s. During those days, dynamic memory chips were much
cheaper and had a larger capacity than static memory. The Intel 8080
must use Intel 8222 to handle the dynamic memory circuit. I cannot
remember because it was a damn long time ago.

Unfortunately, developing the memory board with dynamic memory was not
straightforward compared to the static type because of involved
complicated refresh timing. Several vintage S100 dynamic memory boards
have a delay-line chip to control the memory refresh timing. I
realized a few months ago it is impossible to find the delay-time chip
nowadays.

Here is precise information, https://en.wikipedia.org/wiki/Memory_refresh

Nowadays, the static memory chip is affordable and has a large memory
capacity in a single chip. It is much easier to work with than I did
in the past. Oh my goodness, I remembered a lot of piles with Intel
2102 (1K x 1) with 500nS access time chips that took me a long time to
solder each pin-by-pin IC socket on the PCB. Before that, I used Intel
1101A (256 x 1) with something like 900nS access time and must use two
power sources to run it. I did not know what had happened to my
vintage memory boards. I may have moved a lot and may lose the boards.

Steven

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855B92A86225DA586590C27F7829%40SN6PR01MB3855.prod.exchangelabs.com.

[smb...@gmail.com]

I've been slowly collecting parts to build an S-100 system for that past year or so, and while stowing my latest acquisition, I came across something that's quite the coincidence. There's a D8203, right there!

Unfortunately it's not useful due to two reasons: 1) It's S-100, not H8, and 2) The silly thing is IO-mapped instead of memory mapped, so it's not even a useful reference implementation of the D8203. It does, however implement wait states, so something useful can be gained there. It also gives me validation on the choice of oscillator frequency (it has a 20 MHz crystal).

It's an interesting approach, apparently you write track and sector numbers to a pair of IO ports, and then you can read or write your 256-byte (or 128-byte; it's jumper-selectable) sector from another IO port. It has provisions for battery backup (what would folks use back then? a lead-acid car battery?). As Norberto or Steven would point out, all the RAM ICs on this board could be replaced by a single AS6C4008 SRAM chip. This is giving me a few ideas.

Scott

[Peter Higgins]

Scott - as you have figured out, the S100 Semidisk was an I/O mapped memory board designed for the specific purpose of functioning as a "memory disk". With software provided for CP/M, it was functionally a very fast floppy drive.

CompuPro manufactured a very similar board they called the "M-Drive", which also used DRAM and the 8203 controller and was available with a capacity of up to 2MB. The M-Drive manual and schematic can be found here:

http://www.s100computers.com/Hardware%20Folder/CompuPro/M-Drive/M-Drive.htm

[smb...@gmail.com]

Okay Peter, that's very useful. Unfortunately it has a PLD in the schematic with no list of the equations that drive it, but still I can get some insight from their wait-state generator and other logic. I can see they are working around the same issues I did:

* They use automatic refresh

* They latch the state of IOR and IOW for the duration of the transfer.

* Their wait-state generator starts at the beginning of the bus cycle, guarded by CS, and runs until XACK clears it.

* They latch the address bus, but they don't latch data writes (my assumption is I have to do that, should the XACK come late, but perhaps not)

Their design is simpler than mine. I'm tempted to revise, or even fork off a second board based on their approach. I'll have to think about this.

Scott

[smb...@gmail.com]

Actually, I take that back, they don't latch the address bus -- I'm just looking at the counting circuitry. Still, the wait state generator is useful.

Scott

[Mike Enkelis]

If the board is a “Semidisk”, l was the author of the CP/M self installing software drivers.  I sent a preliminary user’s manual to “deramp.com”.

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Peter Higgins <higgin...@gmail.com>
Sent: Saturday, March 18, 2023 7:59:42 PM

To: SEBHC <se...@googlegroups.com>
Subject: Re: [sebhc] Re: h8-64k-dram

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/ad24f854-1f7d-46bd-b4b6-2a622961192dn%40googlegroups.com.

[smb...@gmail.com]

Yes Mike, I found that manual. No schematics with it though. But at least the manual is there with the programming examples! Nice to hear you worked on that drivers!

My DRAM board is looking somewhat positive. I wired up a waitstate generator that's similar to the one in the compupro schematic that Peter linked. It's much simpler than my own circuit. My experiments show:

* The 8085 board will sit there and run memory test all day long without issue. It'll explode during boot though.

* The Z80 board drops an average of 1 out of every 32 writes, at random. It doesn't write garbage, and it doesn't fail reads. It just drops writes. It could be these are ones where it was busy during refresh and just didn't quite make it.

That's been the story of this board -- it always "almost works". But anyhow, things are looking up -- the respin will feature RC circuits and Schmitt triggers to clean up the MEMR and MEMW signals and to improve timing. 

Scott

[smb...@gmail.com]

The DRAM board is close, but not yet working. Isolated reads and writes work fine. However, a write followed by an instruction fetch will occasionally cause unknown bad things to happen.

Right now I have the computer configured with the DRAM board providing 0xC000 to 0xDFFFF but the SRAM board providing all other RAM addresses.

;---------------------------------------

; Listing 1: this program works fine -- code in DRAM, modifies data in SRAM

org 0xC000
MVI H, 0x80
MVI L, 0x30
INR M
JMP 0xC004

;-------------------------------------

; Listing 2: this program works fine -- code in SRAM, modifies data in DRAM

org 0x8000
MVI H, 0xC0
MVI L, 0x30
INR M
JMP 0x8004

;------------------------------------

; Listing 3: this program intermittently fails -- code in DRAM, modifies data in DRAM

org 0xC000
MVI H, 0xC0
MVI L, 0x30
INR M       ; MOV M,A exhibits similar problem
JMP 0xC004

The problem is the INR M instruction when storing to DRAM occasionally completes late due to a wait state on the write operation. When this happens, if the next operation is a memory read from DRAM (which it will be in listing 3 when we fetch the JMP instruction), the instruction fetch will be corrupted.

The good news is that this is now a known, reliably reproducible bug for me to solve.

Scott

[norberto.collado koyado.com]

WOW! Great progress as this design is complex.

👍

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of smb...@gmail.com <smb...@gmail.com>
Sent: Saturday, March 25, 2023 6:12:39 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/9522d24a-a2ff-4e8a-8c2f-981d60c76e2an%40googlegroups.com.

[Robert Litz]

I used to design dram memory for military computers.  One thing we learned was that using gate delays to provide timing signals to the drams is sketchy.  Gate delays very with wiring layout, temperature, gate vendor, and even part lots.  We ended up using delay lines. They provided much tighter timing. Similar to analog devices DS1005K-100. Might want to look into them.  Tighter timing means shorter cycles.  And better reliability.

[smb...@gmail.com]

Well there's my problem! Picture attached.

I'm holding WAIT while writing the DRAM, and the Z80 asserts MEMR. I'm going to have to get out my technical manual...

Scott

[Douglas Miller]

If I'm reading that correctly, it seems more ominous that you're asserting /WAIT but the CPU ends the MEMW cycle anyway.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/a8c90c4b-67ee-4134-91be-4a90ea7608c1n%40googlegroups.com.

[smb...@gmail.com]

Yes, that's what I'm seeing.

My observation has been that the 8085 will extend READ and/or WRITE cycles when a wait occurs during the cycle. The Z80 and 8080 will extend only READ cycles. During a write they (apparently) sample WAIT before asserting the write strobe. This is contrary to what I would have expected.

Picture is attached from the Z80 datasheet. Look at the timing of !WAIT and !WR. The Wait happens before the !WR, not during.

Scott

[Peter Higgins]

The Z80 only samples the WAIT input at the falling edge of the clock in T2 and (if present) all subsequent T(wait) machine cycles. If a WAIT cycle is to be initiated, the WAIT signal must be pulled low 70ns prior to the fall of the clock in T2 (for a Z80 running at 2MHz). On the other hand, the Z80 write strobe becomes active 90ns after the fall of the clock in T2 (for a Z80 running at 2MHz). The Z80 timing diagram you provided illustrates that for a normal non-extended instruction cycle, the WAIT signal must be high (inactive) with sufficient setup time prior to the fall of the clock in T2. What that timing diagram does not illustrate is what happens if the WAIT signal is pulled low with sufficient setup time prior to the fall of the clock in T2 - in which case the Z80 write strobe would be extended.

The problem I see in your scope tracings is that the WAIT signal is being pulled low just a little later than the MEMW bus strobe becomes active, which is after the Z80's sampling window for the WAIT signal has closed. This is why you are not seeing the MEMW signal being extended.

I don't know how you work around this dilemma within the limitations of the H8 bus. What your RAM board requires is direct access to the Z80 MREQ* and RD* signals, which when combined could be used to generate a WAIT signal with sufficient setup time to extend a memory write cycle.

[smb...@gmail.com]

I just booted HDOS from CompactFlash with the Hellboard installed as the only RAM in the system.  There's not a chance of it booting a H17 at the moment; the timing is probably all screwed up and the board probably performs much worse than SRAM. I will have to benchmark it.

The solution was to use 74LS123, triggered by XACK, to create a delay that blocks the next operation until about 20-30ns after the write has completed. This is together with latching A0..A16 and D0..D7 for the duration of the write.

I think I will do a respin, just so I can change the silkscreen from H8-DRAM to H8-DRAM-HELLBOARD.

[norberto.collado koyado.com]

Congratulations. For better performance, please use 74AHCT123 and  74ALS1005 as shown:

 

 

Norberto

 

From: se...@googlegroups.com <se...@googlegroups.com> On Behalf Of smb...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/232ec391-6a6f-4d99-8a7e-76167a25d4f0n%40googlegroups.com.

[smb...@gmail.com]

Thanks Norberto, I will have to have a look at that.

I ran some more experiments with Hellboard this afternoon:

* Works very inconsistently on the 8085.

* Does not work at all on the 8080. I think the problem on the 8080 is the data arrives on the bus far enough after !WR strobe, that the 8203 is able to complete the write before the data is even present, leading to 0x00 being written.

* Performance penalty is 26% with a 20 MHz crystal in the 8203, or 7% with a 25 MHz crystal. The crystal controls the DRAM timing, so it is not surprising that it affects performance. Still, quite the range...

Scott

[norberto.collado koyado.com]

Does it work fine with the Z80?

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of smb...@gmail.com <smb...@gmail.com>

Sent: Sunday, March 26, 2023 2:57:58 PM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/a7ca22aa-7dde-48b8-8055-f2702257c1e6n%40googlegroups.com.

[Scott Baker]

Z80 is what I'm using it with. Depends on your definition of "fine". :)

It'll boot compactflash, but not floppy. I'll work at 2 MHz but not 4 MHz. You have to get it into a good mood before it'll boot successfully. Once it's in a good mood, you can reset it and reboot as much as you want. You can even power cycle it. Unfortunately, I'm not yet sure what gets it into a good mood yet.

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB385592D70E41A64124EE2F1CF78B9%40SN6PR01MB3855.prod.exchangelabs.com.

[smb...@gmail.com]

Applying the work in the other thread on reverse engineering the H8-64K-DRAM board, I have it almost working on 8085. I just have to narrow it down to why the board is sometimes in a 'good mood" and somethings in a "bad mood".

* I'm using 8080-32K ROM version 2.0(alpha9)

* It's in a bad mood when first powered on. It remains in a bad mood until you a) attempt to boot floppy, and then b) run memory test at least 4 times. Running memory test only once will leave it in a bad mood.

* While in a bad mood, the monitor menu works, but running "XC" (front panel clock) will print gibberish. Booting HDOS will fail at approximately the point where it should be printing the HDOS boot prompt. It prints no boot prompt and accepts no keyboard input.

* While in a good mood (after the 4 memory tests), it remains in a good mood until powered down for at least 1.5 minutes. If you power down for just 1 minute, it'll stay in a good mood when powered back up.

The only thing I can wrap my mind about that's different is the memory initialized between 0x2000 and 0xFFFF. The values written are different on memory test pass 4 than they are on memory test pass 1. Perhaps the 32K ROM is either failing to initialized a variable (seems doubtful) or whatever instruction is initializing the variable is failing to execute on my DRAM board (seems more plausible). 

Any thoughts?

Scott

[norberto.collado koyado.com]

I think you have the 8080A 64KB memory board. Just set the 8080A to have a gap between both boards. So, on power-on the CPU will see only the 8080A RAM board. Then you can use the front panel to manually test the DRAM board. Or write a program to exercise it.

 

At least the 8080A 64K board will provide an stable environment to debug the DRAM board.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5c5ee4f6-a1bb-43eb-a008-22e7605ec6cdn%40googlegroups.com.

[Scott Baker]

Putting a gap between the two boards and manually fiddling with setting and reading from the DRAM board works fine.

I'm unable to reproduce the problem with any artificially constructed tests... which means I need to make better tests.

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB3855484D0868A7D8FB9BDE18F7929%40SN6PR01MB3855.prod.exchangelabs.com.

[smb...@gmail.com]

I had a little bit of success tonight.

I managed to narrow the difference between "good mood" and "bad mood" down to the sole contents of exactly one memory address, 0x2FEB. If this address has 0x00 in it at boot, then the XC (Display Clock) command prints gibberish. If the lower two bits are both 1s, then the XC command works fine. So far as I could tell, nothing reads or writes RAM address 0x2FEB in the 32KB bootloader. So this was a mystery, until I realized that port 0xEB happens to be the 16550's line parameters register, and the bottom two bits are the the number of serial data bits, and 0x00 would be 5-bits, and 5-bit serial would surely look like gibberish on any terminal.

Scope confirms what happened. Now I just need to figure out why.

Scott

[Douglas Miller]

I don't know off-hand what the 8080 puts on A8-A15 during I/O instructions, but it sounds like maybe I/O and memory cycles are getting confused - as if an I/O read/write is getting turned into a memory read/write - or even duplicated to a memory read/write.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/203f5468-b11c-4f96-b263-8b92aa1af844n%40googlegroups.com.

[smb...@gmail.com]

The width of that IOW pulse is tiny, and the amplitude on IOW_BUS is also small (but not small enough). I don't think it's a real IO. It's some kind of noise. For whatever reason, I've been plagued with bus reliability issues since the first few H8 boards that I built.

As for what's on A8..A15 during an IN or an OUT, I believe the 8080 puts the 8-bit IO port address on both A0..A7 and A8..A15. So an IN/OUT of port 0xEB would never result in 0x2FEB being put on the address bus (it would put 0xEBEB on the bus).

Scott

[norberto.collado koyado.com]

Are you using my GAL 444-61 for I/O control? If yes, please use this version: http://koyado.com/heathkit/New-H8-Website/download/z180-444-61%20(1).zip

 

And it uses the IORQ and MI signals as inputs. For IORQ, I “OR-Gate” I/OR and I/OW.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/fb0607ec-cfb1-4ee8-a47c-7d996749d669n%40googlegroups.com.

[smb...@gmail.com]

This is with my 8085 board (hence no IOREQ). It's more forgiving on the timing than the 8080 or Z80, so I'm getting it right before moving to the Z80 or 8080 boards.

Regardless, it feels like the bus problems go all the way back to when I was using the original H8 8080 board together with Les's H8-4 serial board.

Version 4 of the H8-DRAM board just shipped from jlcpcb tonight. Might have it by the weekend. If not, next week. This one will make it easier to adjust the DRAM wait timing until I can find a setting that works for the 8080 and the Z80. I had hoped it would be the final revision, but I'm not so sure. I'm starting to think I should embrace Willis's plan of just cloning his DRAM board part-for-part.

Scott

[norberto.collado koyado.com]

I'm starting to think I should embrace Willis's plan of just cloning his DRAM board part-for-part.

 

This is a good idea at least to have a baseline of a working board. Once you have something working, then you can expand it as needed with new features.

 

On my boards, I tried to use the original design from Heathkit to get the board working and then I add features to such design. Most of the times, I find schematics issues, which causes debug issues. At least the H89 schematics are more accurate when compared with the H8 schematics.

 

On the evolution of the Z80, I started by fixing Les Z80 V2.1 design and came with the following progression:

1. H8-Z80-64-v2.6
2. H8-Z80-64K-RTC-ORG0-v3.x
3. H8-Z80-64K-RTC-ORG0-v4.x
4. H8-Z180-1MB-RTC—ORG0-v5.x
5. H8-8080A-EEPROM-64KB RAM-UART-HA8-8 v1.x
6. Then last H8-8085A-EEPROM-64KB RAM-UART-HA8-8 v1.x (leverage your design).

 

Thanks,

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/3a15a62d-b2d5-4ae9-bcab-ba2cdb7e64een%40googlegroups.com.

[Willis Blackburn]

It's not much of a plan, more of a musing. :-)

Scott, I'm sorry I haven't gotten back to you to confirm those connections, I haven't been able to get to it. I will have some time tonight.

[smb...@gmail.com]

Thanks Norberto and Willis.

I think there's two different situations going on in my case.

1) The bus instability described above, noted particularly when using my 8085 board, but also potentially happening with other CPUs as well. I don't have a good answer for this, though it does seem like moving from HCT logic to LS logic generally makes things better.

2) A timing issue with the 8080 and Z80. There are very specific requirements when operating on the Z80 and 8080. If you start the DRAM write cycle too late, you'll miss the Z80's write entirely as the Z80 /WR pulse is fairly short. If you start the write cycle too early, then you'll end up writing blank data on the 8080, because the data doesn't arrive on the 8080 bus until some time after the start of the /WR pulse. Switching logic families, using PLDs, etc., all impact this timing. Willis's board has a specific Resistor/Capacitor to delay the CAS signal, and those values do not work with my board. Logic family matters here. If the original board chose to use a 74S03 instead of a 74LS03, it might not have been by accident or due to parts availability, but could be because they were expecting a specific timing from the 'S' part.

Designing a DRAM circuit that accommodates different CPUs is especially tricky, as each one (8080, 8085, and Z80) all have different quirks in the memory cycles.

Scott

[smb...@gmail.com]

Took some measurements today with the logic analyzer. One of the places I've been concerned about is the latency between the MEMR signal from the bus and the RD signal to the D8203. Same concern for the MEMW and WR. Willis's board used a 74S03, and I've been wondering if that choice of 'S' logic was intentional. This are my measurements of the delay from MEMR to RD in various logic configurations:

1) 74S03: 4ns

2) 74HCT14 or 74LS14: 14ns

3) 74HCT14 or 74LS14, followed by GAL22V10D-7: 18ns

Each of these measurements can be assumed to be +/- a nanosecond or two (the 74*14, in particular registered between 12 and 16ns on my logic analyzer). (1) is what is implemented on Willis's board, (2) and (3) are what I implemented on mine.

My implementation is a solid 10-14ns further behind the original. The width of a /WR pulse on a 2MHz Z80 is about 480ns. So I'm using up an additional 14ns out of that 480ns budget. 

[norberto.collado koyado.com]

You should use same IC’s. On the H89 circuit below, I had to use 74LS as the “S” version failed.  Heath did recommend to use the “S” but the H89 will not work. I have three H89’s and they all use the “LS” version.

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/763cd2c8-225e-4ac2-ac2d-47b9d727a5can%40googlegroups.com.

[smb...@gmail.com]

The DRAM Board is now booting HDOS3 on the 8080, and on the 8085. I haven't done anything with the /RD logic yet. I'm still using 74LS14 together with the GAL22V10D-7 as was used in the previous prototype (~ 18ns of delay from MEMR to /RD).

I don't think there's any hope this version will work with the Z80 though. I think the Z80 write cycle is too short. Might have to continue to tweak the timing to get it to wokr. I know that Willis's board can do it, because the other owner I've been in contact tested it with a Z80.

Scott

[norberto.collado koyado.com]

For the write cycle, can you use this circuit? Just updated to use the /O2 clock on U112 pin 11 and /MEMW on pin 3 of U111. Also check what Trionyx did  their Z80 CPU board as they had so many options.

 

http://koyado.com/Heathkit/Z-H8_CPU_Board.html

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/c7e00da1-dc64-4ce6-933a-0d6d1726e534n%40googlegroups.com.

[smb...@gmail.com]

Interesting. The Trionyx and the HA-8-6 boards both implement early write. From the HA-8-6 documentation:

"An early memory write signal can be generated by
sampling RFSH (Refresh), MREQ (Memory Request),
and BMEMR (Buffered Memory Read). U12A and
U25A do just that. RFSH and MREQ are ANDed by
U25A, whose output will go high when MREQ is
asserted and RFSH is not. This will enable U12A to
latch the state of BMEMR with the next low-to-high
transition of the CPU clock. If BMEMR is not asserted,
pin 6 of U12 will go low for EMEMW [Enable Memory
Write) to indicate a write operation. If BMEMR is
asserted, pin 6 will remain high. When MREQ is ne-
gated, pin 1 of U12 will go low. This resets U12,
causing pin 6 to go high, indicating the end of the
write operation. This early write pulse will be put on
the bus ifa jumper is connected between E49 and E51."

Basically, it assumes if you're doing something with memory that's not reading, then you must be writing.

The SEBHC Z80 board implements "normal write", synthesizing /MW from /MREQ and /WR like any sane person reading the Z80 datasheet would do. The typical sane person would probably also use just Z80 /REFRESH to perform refresh. But we operate in the space of a bus that was designed for an 8080 using static RAM, not a Z80 using dynamic RAM.

My measurements over the weekend showed that there just isn't enough time with Normal Write to accomplish the worst case of a refresh being in progress. At 2MHz the Z80 WR pulse is 480ns. I measured a refresh at 390ns. Datasheet says it needs five 8203A clocks after refresh before WR, which is another 200ns. Worst case is we started a refresh at the same time the CPU wants to write, so 390 + 200 = 590ns before the DRAM controller is ready for the /WR. 590 > 480, so the DRAM controller outright misses WR operation and the write is lost. This is exactly what I've seen happening.

My guess is it's not easily fixable with the SEBHC Z80 board, short of implementing "Early Write" as an option. It would be interesting to know if Willis's board does or does not work with the SEBHC Z80. Willis, you ought to build a Z80 board some time and find out. It's a great board with many useful features.

Scott

[smb...@gmail.com]

The next revision of the H8-DRAM board should be hitting DHL tonight and ought to have it by the weekend. This one will nail it -- the previous one had the design right, but a few implementation errors that I wanted to fix. I also cleaned up some of the cruft of old unused parts that were abandoned in the design, to clean up the routing.

I've also designed a small piggyback board so I can try out "early write" on the SEBHC Z80 board, and verify that's what the holdup is with getting the DRAM board to work on the Z80.

I think I've learned all there is to learn from Willis's DRAM board. Thanks again Willis for all the help.

Scott

[norberto.collado koyado.com]

Your perseverance is incredible/admirable despite all difficulties to achieve the supreme goal of having such board Dynamic memory board work with the 8080A/8085A/Z80 CPU cards.

 

Thank you,

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/47555c80-6c34-46b9-a1b6-aaec470177cdn%40googlegroups.com.

[smb...@gmail.com]

I can just be unreasonably stubborn at times. Once I actually have this thing proven to be working and know I understand the various design issues, I'll probably never use it again (SRAM is just so much more convenient!).

I learned a lot about DRAM controllers during this experience.

Scott

[norberto.collado koyado.com]

It is a great feeling once it is working great after so much work. 

Thank you for following thru on this design. 

Norberto 

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of smb...@gmail.com <smb...@gmail.com>

Sent: Monday, April 17, 2023 6:43:21 AM

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/0df20722-8611-4235-b76b-37c7b8d4ec70n%40googlegroups.com.

[smb...@gmail.com]

One of the nagging issues has been the "good mood" / "bad mood" behavior depending on whether I use 32KROM memory test to clear out the memory. I think last night I finally came up with a resolution for that.

It came down to address 040-327. When set to 004, HDOS 3.02 will hang prior to displaying the boot prompt. When set to any other value with bit#2 unset, it boots fine. Turns out this memory location is S.CONTY, which is the terminal type. 

CTP.BKS EQU     10000000B               ; TERMINAL PROCESSES BACKSPACES
CTP.FF  EQU     01000000B               ; Terminal Processes Form-Feed
CTP.MLI EQU     00100000B               ; MAP LOWER CASE TO UPPER ON INPUT
CTP.MLO EQU     00010000B               ; MAP LOWER CASE TO UPPER ON OUTPUT
CTP.2SB EQU     00001000B               ; TERMINAL NEEDS TWO STOP BITS
CTP.HHS EQU     00000100B               ; Terminal uses hdwr handshake  /3.0a/
CTP.BKM EQU     00000010B               ; MAP BKSP (UPON INPUT) TO RUBOUT
CTP.TAB EQU     00000001B               ; TERMINAL SUPPORTS TAB CHARACTERS

So bit#2 turns on hardware handshake, which I'm not using, and prevents terminal output. As far as I can tell, the HDOS 3.02 loader does not initialize this variable prior to displaying the boot prompt. I can reproduce the failure by setting 040-327 to 004 on the front panel, using my factory 8080 board together with Norberto's H8_8080A_64K_RAm_Brd. 

A mystery solved.

Scott

[Joseph Travis]

It appears that "feature" was added for HDOS3.  I admire your tenacity to find the root cause.  Congrats!

BR,

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/5be722ae-0a78-4be5-9f2c-5eecaeec718cn%40googlegroups.com.

[smb...@gmail.com]

Success! I just booted HDOS3 using the Z80 board with my "early write" daughterboard attached. Now tested and working on 8080, 8085, and Z80. Pictures attached of the Z80-board w/ Early Write, final revision of H8-64K-DRAM, and some scope traces of early write.

Some background one the scope traces. The second trace down is the traditional "MEMW" signal (displayed inverted here, active-low). You can see that MEMW usually asserts about half way through the T2 cycle. The early-write (top trace) happens about half a clock sooner, at the very beginning of the T2 cycle. This provides sufficient time for the DRAM controller to inject the write wait state. The early write schematic is show and described in the H8-6 documentation, though the schematic itself has several errors.

A bit of a writeup on the website and some release of schematics, and I can finally close this one out as COMPLETE.

Scott

[glenn.f...@gmail.com]

Congratulations scott. You certainly poured your all into this effort!

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1f385cad-606e-4d04-af11-eb518b9f9d24n%40googlegroups.com.

[norberto.collado koyado.com]

WOW!  Great to see it working. I will like to get one of the Z80 early write module to do some testing here.

 

Thanks,

Norberto

 

Norberto

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/01df01d97634%24aae43600%2400aca200%24%40gmail.com.

[Joseph Travis]

Congrats once again!

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/SN6PR01MB38556FB27851CA5A838EAD54F7669%40SN6PR01MB3855.prod.exchangelabs.com.

[Les Bird]

Scott,

Yes the HA8-6 schematic is full of errors. When I was laying out the HA8-6 replica board I tried to fix as many of them as I could find. I posted the new schematic with most of the issues fixed on the Wiki: https://github.com/sebhc/sebhc/blob/master/documentation/hardware/H8/HA-8-6%20Z80%20CPU%20Circuit%20Board%20Operation%20and%20Service%20Manual%20Schemtic%20Part%20of%20595-2652.jpg

However, there are still more errors. I would need a working HA8-6 to trace and fix the rest of the errors so until then I put my HA8-6 replica board on hold. Keeping my eye on eBay for any HA8-6's to show up.

Les

[Scott Baker]

Writeup in progress is at https://www.smbaker.com/designing-a-dram-board-for-the-heathkit-h8-computer-using-the-intel-d8203-dram-controller. Gerbers and schematics are published in the github repo linked to the same article.

Norberto, I need to do a respin of the early write board. Unfortunately, I had the VCC and GND pins swapped on the Z80 footprints, and this necessitated some ugly rework (its not easy to disconnect pins from a ground plane) on the bottom half of the board. It didn't actually affect the Z80, but the other two smaller ICs on the board were powered backwards. It didn't actually hurt them either. The polulu switching regulator probably shut down, preventing hot silicon from flying across the room. Anyhow, bottom line is I need to respin that little daughterboard.

Scott

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/92d6ad4f-e204-4b41-9c7d-7b0713d9a50en%40googlegroups.com.

[norberto.collado koyado.com]

Thanks for the update!

Get Outlook for iOS

---

From: se...@googlegroups.com <se...@googlegroups.com> on behalf of Scott Baker <smb...@gmail.com>
Sent: Sunday, April 23, 2023 7:35:53 PM
To: se...@googlegroups.com <se...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CA%2B8qVMPgrrsLefWuHqiTz6VygqPHenGA-iefJ8XEp%2B3txCxf0Q%40mail.gmail.com.

[Joseph Travis]

Les,

I can send you a WH8-64 for you to look at once I get my boards back from Glenn.  Please PM me with your address if you are interested.

BR,

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/92d6ad4f-e204-4b41-9c7d-7b0713d9a50en%40googlegroups.com.

[Les Bird]

Joe, do you mean HA8-6 the Heathkit Z80 board? I do already have the WH8-64 64K Heathkit RAM board.

Les

[Joseph Travis]

'Sorry Les, I confused myself.  The original thread was about an H8 64K DRAM board and I misunderstood that you are looking for an original Z80 board.

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/068aacb7-7379-4319-ad15-b24c8b1b0342n%40googlegroups.com.