RC214 - Altair

[steveukman]

Starting with a huge "Thank You" for all of the inspiration from the group and the individuals that have given specific guidance off-group.

This morning my MKII Altair Front Panel integration with the RC2104 passed its test suite.

The prime objective is to have all of the diagnostics and control provided by an Altair front panel with the hardware flexibility of the RC2014 architecture (something missing from the modern Altair clones).  Okay .... and to look cool.

A Mike Davis Altair case, 'Stock' RC2014, Steve Cousins backplane (slightly modified to allow instruction injection) as well as a custom panel interface & bus controller cards to interface the front panel to the RC2014 bus and provide the necessary ability to perform the Examine, Deposit and similar functions.

I did use a few GALs to consolidate the logic as well as to attempt to provide some 8080 functions (e.g. peek the IACK and M1 cycles to detect EI, DI instructions to populate the INTE LED).  

In controlling the bus during WAIT states I realized that I could actually perform some memory and IO cycles so a future development would be to 'poke' some IO settings during a reset (e.g. to program the 512K memory card registers to select ROM / RAM options).

Yes .. some cheats ... a 328P to help the panel interface logic and I made the cards sized for a Altair frame.  I hope that these transgressions do not get me 'sent to Coventry'.

Thanks again for rekindling the sense of fun that I had making ZX81 add ons.

Steve

[William Huskey]

This is cool, did you put your stuff on GitHub or somewhere others cna give it a try? 

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/32ebb658-dfca-4ce5-8b19-5ff8cef5b615n%40googlegroups.com.

[steveukman]

Not yet ... I am still working through some of the features, so the design is not yet complete.

The circuitry to emulate Run/STOP/SINGLESTEP as well as the ingenious Examine and Deposit switches  (that inject JMP and NOP instructions onto the Z80 bus) works well.

To Do is to perform a simple DMA during reboot to (re)configure the hardware (mainly paged ROM/RAM as the Altair had all RAM by default, but selecting the SC Monitor is really useful).  I may extend this on a modified memory card design to pre-select a boot configuration.... replacing the pull down resistors with a shift register and output enable glue-logic.  

I originally used the SMBaker I2C bus manager design for data and address injection ... but found it to be horribly slow (about 86 seconds to read or write 64K of memory ... about 760 bytes per second) due of the complexities of the I2C protocol and overhead).  Using shift registers it looks like I may be able to get well over 64K per second.  At those speeds, if I am not booting to RomWBW, then I may just copy the monitor, BASIC or CP/M to RAM.  This is still to be tested.

The design also includes a card chassis (2020 t-slot extrusions) and 3D printed card guides & bases for the SC113 bus boards to make a more complete system, so I have a few more 'moving parts'  to integrate.

With the move to 8800 board size, I have room for a QSIO - a Z80 SIO (for RC2014 compatibility) plus dual ACIAs (for 8800 support).  Again, the boot-time configuration will help with  potential address conflicts between the customary Altair ACIA I/O addresses and some of the RC2014 peripherals.

At the moment, I am really happy with the front panel level of control, being able to single step and communicate with the Monitor at a machine cycle level.  Okay ... and the blinkenlights.

Is it cheating to use the monitor to enter the code for the "Kill the Bit" game?

Steve

[Tom Plano]

Would you mind elaborating on what you did to the back plane to enable instruction injection? Further, the Altair CPU card (and S100 bus in general) expects pull ups on the D0-D7 lines to the front panel, which is all fine and good in a fully buffered s100 system, but I imagine could pose a problem integrating with the un-buffered RC2014.

Very cool project, looking forward to hearing more about it

Tom

[William DesLauriers]

Your project looks very interesting and promising!  Can you use a small FPGA chip instead of several GALs?

Wm

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/d9f68546-571a-451a-9a15-4a9648eabf84n%40googlegroups.com.

[steveukman]

Thanks Tom.  

This is a 'winter project' with the idea of getting into a full emulation and functional retro rig by 2025 (50th anniversary .... so I am musing with a designation of RC8850).  I am away from my personal rig but will post answers to the best of my recollection.

The MKI used three backplane slots for the processor (I probably only needed 2).  Between the processor slots and the rest of the backplane I cut the /RD and /WR tracks.  Slot 1 holds the processor.  Slot 2 had jumpers between the /Z80RD, /Z80WR and 'spare' backplane lines.

The Front Panel Interface (FPI) card used the Z80 /RD and /WR lines to (re)generate the Bus /RD and /WR.  In RUN mode it was just gated through.  In "Inject" mode it could control the bus to have the processor read the injected JMP XXXX and NOP instructions, read from memory and write, overriding the Z80 signals as necessary.

The  FPI buffered (with drivers for the LEDs as necessary) all signals before transmitting them via the ribbon cable to Mike Davis' front panel, so they presented a single TTL load to the RC2014 bus.  As I mentioned, the FPI has some logic (including some basic state analysis) to generate some of the LED.

The FPI has a (retro looking DIP) ATmega328 to read the front panel shift registers (that encode the switches).

Meanwhile, I decided to go for a MK II version for a few reasons:

1. The I2C injection was far too slow at 760 bytes per second

2. Limitations in controlling the bus

3. Use cases requiring more complete control over the processor and bus reset

4. Use cases for enhancing the configuration and overall use

MKII has

1. Standard bus (no cut tracks)

2. Simplified FPI (removed inject logic).  ATmega transmits the switch status via a serial port over a 'spare' bus line.

3. New Z80 card with some changes 

Z80 card now has all of the bus control logic to allow reset management, DMA and Injection.  

It also has an Arduino to read the switches and initiate bus control functions.

Reset - Several modes are now possible.  The Z80 and Bus can be independently reset.  This allows the Bus reset to be released before the Z80, with better control over the timing.  It also allows the generation of I/O cycles and selected  peripherals to be 'initialized' before the Z80 is released from reset.  For the programmable memory cards, they can be configured (All RAM for CP/M, BASIC ROM, Monitor etc.) according to boot switch settings before the Z80 starts.  This makes configuration pretty flexible.

Bus Control / DMA to load RAM and configure peripherals from the Arduino.  All use the same buffer and bus control chips, simplifying the overall design to support 4 modes of operation (Normal Run, SS/Inject, CPU Card Controller I/M & DMA, RC2014 Bus DMA)

 

Injection speeds have increased from 760 bytes / sec to 66K for the memory injection.

This winter I hope to get the memory and IO configuration manager to work so that I can select CP/M, BASIC and Monitor modes.

I am working on the ASAD memory card that uses the paged design and can operate in (i) selectable default configuration of RAM/ROM (ii) Paged RAM / ROM (where the boot process can configure it) and (iii) linear mode to support a future Z180 card.

Future work may include 'intelligent peripherals' ... e.g. a graphics card the presents a UART interface to the IO map.

[steveukman]

I do like the idea of a FPGA and am considering using something for some additional 'intelligent' peripherals.  They certainly have a lot of potential.

I chose GALs for

1. The retro look

2. 5V capability

3. Familiarity with PALASM from my past

4. Easier to develop systems in smaller steps and to debug using simple tools

5. Still freely available and cheap on eBay

They are a real pain to get sequential logic working (I use plenty of 74LS74s and latches for state management).

What are recommendation for something that is simple, DIP, 5V tolerant and looks like it belongs?  What are the tools like?

I have toyed with the idea of having a 'bus bridge' connecting several of Steve Cousins' bus cards so that part of the bus is 5V and part is 3V3.  For simple operations that would be a nice solution, but I wonder if Open Collector, DMA and similar considerations may either place constraints or make for a complicated solution?

It would open the door to both FPGA and Propeller type solutions.

I would appreciate any suggestions.

Thanks

Steve

[Greg Holdren]

There are also CPLDs which is a step in between PAL/GALs and FPGAs. Plenty Altera 7100S and Xilinx 9500 series on eBay and old stock. Shipping new are the Atmel ATF1500 series. All 5V. Smallest package size is 44 pin PLCC vs the largest PAL/GAL Sq In is close. More logical/gate for the size. Software is better IMHO along with Verilog or VHDL or schematic entry.

Greg

[Tom Plano]

Not sure how close this is to what you'd come up with Steve, for the MK1 version, but Id been toying around with the idea of a stackable cpu card buffer. Ive included it here. It main idea was to keep the RAM (and other devices) from noticing that anything funny was going on. The ~SigBlock line puts the data bus and control lines into a high impedance state for bypassing by my front panel.  You'll also notice the pull ups on the unbuffered data-lines to support the opcode injection, a la S100. Its possible that this is a very over complicated way to go about this, and there is the side effect that I cant use the FP to look at the I/O addresses, so suggestions are welcome.

Tom

[Mark T]

I think you have four times as many buffers as you need. Use a single ‘245 and use the direction control. For read and write maybe use a ‘365 though you could still use another ‘245, it only needs to drive the bus. You might also buffer the other control signals.

The way you have the buffers connected they will be latching up the bus due to feedback as you have both directions enabled at the same time.

[Tom Plano]

What I really wanted was a bi-directional gate, high impedance in the enabled state and passive (bidirectional) pass-through otherwise.   I didn't consider the feed back from driven lines, honestly so that's a good point. I could possibly tie the directional control to the WR/RD lines with some glue logic that accepts my ~SigBlock signal to disable passing. That strays close to a circuit timing problem though, that I have far less confidence in solving. I would be very happy to believe you if you told me that propagation delay/timing isn't a problem at the 8ish MHz of the system clock.

 

Tom

[Mark T]

I don’t think you will have a problem with propagation delays at the 7.37 MHz standard clock speed. Unless you are using older memory and Input output devices.

You could use SigBlock, active high to block to control the active low CE of the ‘245. Then I think you want the direction towards the z80 when either /RD or /M1 are low. Don’t use /WR for direction away from z80 as it is too late in the z80 cycle and the z80 outputs are already active. /M1 is included to allow the z80 to read interupt vectors during an interupt acknowledge cycle.

If you are using DMA in your system you probably want to disable the buffer when the z80 /BUSAK is active.

Select either an AND gate or NAND gate to combine /RD and /WR, depending on how you wire the A or B from the z80. Spare NAND gates are sometimes more useful for other glue logic, but I would probably choose the direction for the buffer to simplify the pcb layout. Its one of the design trade offs to be considered.

Use another ‘245 for the control signals with the direction fixed away from the z80. Or use a ‘244, ‘365, etc to buffer the control signals. You might also buffer the other control signals from the z80 to the bus, depending on how the rest of your system is going to work.

74HCT series might be a better choice than 74LS, as the inputs are higher impedance. This could help if you have older components on your databus, that might not have high output drive capability. The 74HCT245 is slightly faster than the 74LS245.

[Mark T]

I read through the earlier posts again. If the reason for isolating the data bus is so you can inject instructions to the z80 then you don’t need the buffer on the data lines. So long as you don’t enable the read or write lines from the z80 to the bus then the other modules in the system will ignore anything on the databus and will not try to drive the data bus themselves.

If you then want to inject instructions to the z80, use a buffer to drive the instruction on the bus while /RD and /WR are disabled. If you have two different instructions to inject use two 74LS257 (or HCT) as two ‘257s takes less board space than two ‘245s. If there are more than two instructions consider using an eprom and controlling the address lines of the eprom.

It would be safer to also disable /MREQ and /IORQ, as some modules might not use both /RD and /WR.

[Tom Plano]

I'm wondering if it is worth it to include some logic to manage BusReq/BusAck signals. I cant think of any cards that use the signal off the top of my head, but I also don't imagine that it would be very hard to support.

[Alan Cox]

On Mon, 4 Oct 2021 at 16:51, Tom Plano <tom.p...@gmail.com> wrote:

I'm wondering if it is worth it to include some logic to manage BusReq/BusAck signals. I cant think of any cards that use the signal off the top of my head, but I also don't imagine that it would be very hard to support.

The Z80DMA card uses them. I think it's the only one that does, so it's not a common setup.

Alan

[steveukman]

It could be useful (and not too difficult). I am using it to have a simple controller save and load memory contents. IIRC Scott Baker and others used DMA to dump RAM contents to a card. 

Initial successful experiments have me thinking about avoiding ROMs, by having images of the CP/M bootloader, BASIC and Monitor .... hitting the "Reset" switch with one of the Aux, Protect etc. switches set would load RAM with the selected image before releasing the processor.  

Pre-configuration of hardware via IO DMA is another (sub) use case.

An all RAM multiboot capability could be nice.

I did consider using BusReq to have (create) an ICE capability,  but developing one would be a significant diversion. Besides, the Altair front panel gets me 56.4% of the way there.

Z180 has DMA embedded, so something else to consider as a possible use case.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/uyVvgV9mYWQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAK9X0%2BuvoAdOq1XjD9nmiR%3DMxH4cciXYqJLe2thgmrwbH1m%2BzA%40mail.gmail.com.

[Mark T]

Hi Steve,

I have used an ft245 injecting instructions to the z80 for a RAM only system with battery backup. This uses z80 wait to have the z80 wait for the next instruction that is to be injected. This was a single board which included blocking /RD from the ram, so it might be a usefull reference for what you are working on. Search for ft245 in this group should find it.

Another thought on injecting instructions to the z80, as the NOP is 00. If you are injecting either NOP or one other instruction you only need one buffer, as you connect the inputs to the buffer for the alternate instruction to a control circuit to choose NOP when low or the alternate instruction when high. If you used two of ‘257 this could switch between NOP or alternate instruction on one set of inputs and panel switches on the other inputs. Possibly multiplex from two sets of switches using diodes if you wanted to apply a target address for a jump instruction. /M1 could be used to select between instruction or target.

Quite some time ago I made a z80 board with toggle switches. This was similar to your original idea of blocking the data bus but only injected NOP to step to the next address. To jump to a different address I need to program a jump in ram at 0 and single step the jump after reset. Maybe one day I’ll try and improve it. I might wait and see what you come up with first. I’m playing with INS8060s just now so it could be quite some time in the future.

Mark