Memory mapped video interface

[Jan S]

Hi all

This is a project, that has been in the pipeline for a while.
[part 1 (alpha version)]

General Description:

IDT7130 is a dual port RAM, which means that it's memory content can be accessed/modified from two sides (ports A & B) - largely independently.

Port A is facing our Z80, and should by all means act just like any other ordinary static RAM. Read/Write/TheWorks.

Port B will be facing a curcuit, that reads the contents at places corresponding ASCII chars on the screen (Very much like the Nascom does). The plan is to use a Propeller CPU to generate a VGA output. Not unlike Marco's VGA serial Terminal - without being serial.

In this early version (0.1) only Port A is used. And as such it's just seen as RAM. When this works, I'll continue with the Port B circuit :-)

Here goes:   Version 0.1:

The IDT7130 (35 nS version) is wired up as normal 1 Kb static RAM block. U1 [74LS688] will (along with dip switch block SW1) act as memory window selector. Only 6 most significant addr-bits are used; giving us a 1 Kb relocateable window.

Example:
Switch 1..2: Dont care (not used).
Switch 3:    HIGH
Switch 4..8: LOW
...gives us RAM window 0800H...0BFFH

Selecting an address window: (Port A)
U1 - pin19 goes low when address is inside the by SW3..8 selected window. Combined with (/MREQ) gives us a useable RAM Chip Enable (/CE).

RAM Write is obtained combining (/CE) and (/WR).
RAM Read is obtained combining (/CE) and (/RD) and effectuated by pulling (/OE) low.

(/BSY) pins are really outputs, but are pulled high anyway.
(/INT) pins are really outputs, but are pulled high anyway.

On Port B only: (/CE) and (/OE) pulled HIGH as the comming video-curcuit will be reading more or less all the time.

Only "problem" would be if a "WRITE" was attempted on both ports on the same time. As this is not possible here, I'll ignore it.


Comments are welcome :-)
/Jan

[Jay Cotton]

This sounds like a fun project.

One thing.   Your memory will cut into the z80 address space, and thus reduce the executable space

of the z80.

You might look at a port addressable memory option instead.   Somewhat harder to use but it will not

eat into the program space.

my 2 cents

JC

[James Knox]

Another option would be to map the memory into another bank so it would bank switch with the installed memory. I am unsure weather this would be the lower 32 or the upper 32, but this may be a simpler option than to mapped memory

James Knox

--
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 post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5a510636-3ae2-4a1c-94fe-fe2815ac2d07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jan S]

Jay and James, right You are.

Here are a few of my considerations:

Non-CP/M:
Having a nice and direct (very fast) screen output outweights the loss of one Kb RAM.
And - I might add - Stephens brilliant monitor could come ind quite handy here :-)

CP/M:
By running CP/M, You're probably using a terminal as output console anyway, so use the dual-port ram as ordinary ram (and either ignore or switch off the VGA screen).

Banked memory space (ROM/RAM):
Still need to thing this through.

Issues in general:
If I "claim" one Kb of RAM out of the 64Kb space, I need to be able to "disable" ram on other bords while addressing the videoram. And none of the RAM/ROM or Combined RAM/ROM boards are constructed to handle this. So there's an issue that I need to handle anyway.

This is work in progress. Nothing is final and thoughts on this are received with thanks :-)

/Jan

[Spencer Owen]

On 14 May 2018 at 17:57, Jan S <futt...@gmail.com> wrote:

If I "claim" one Kb of RAM out of the 64Kb space, I need to be able to "disable" ram on other bords while addressing the videoram. And none of the RAM/ROM or Combined RAM/ROM boards are constructed to handle this. So there's an issue that I need to handle anyway.

Hmmm... not really. If you write data to an address and two different RAMs are at that address, then that data gets written to both places.  So that 1kb of space can exist on both an existing RAM board and your video board.  The only major caveat is that from the Z80 point of view, your video RAM should be write only, otherwise if you read and those two locations have different data then you've got problems on the data bus.  As your video generating circuit is only reading from the other side of the video RAM then that won't touch the RC2014 RAM so that shouldn't be a problem.

For a non-CP/M RC2014, that memory area could even be at the very bottom of memory where the ROM lives.  Any writes to the lowest addresses are ignored on the ROM module, and as long as read from your video RAM (from the Z80 side) is not possible, then that should work fine.

Spencer

[Shaun ONeil]

> If I "claim" one Kb of RAM out of the 64Kb space, I need to be able to "disable" ram on other bords while addressing the videoram. And none of the RAM/ROM or Combined RAM/ROM boards are constructed to handle this. So there's an issue that I need to handle anyway.

There is the option for shadow ram here.  In a nutshell, you put your video ram in the same address space as existing rom.  And then just don't answer reads.  So when you read from this address space, the rom writes out its values and the video ram does nothing.  But if you write to this space, the rom does nothing with it (it can't), but the write does land in vram.

I have no idea how this would work with banking, but for a flat address space, it's a handy way to have your cake and eat it (as long as you don't have more vram than rom).

[Steve Cousins]

Hi Jan

I think a memory mapped screen is probably the single biggest retro feature missing on the RC2014. 

I tend to think of my interest in the RC2014 as being a recreation of 1978 to about 1985 era computer technology. I know we cheat a bit with larger memory chips and the like, but it is a reasonable approximation. 

While CP/M machines of that era often had terminals, most home computers had memory mapped screens. A retro computer without a memory mapped screen does not feel authentic to me. So I think what you are doing is great.

I like Spencer's suggestion of making the dual port RAM overlay existing RAM and being write only on the processor side. That nicely fixes the problem of having to make a hole in the existing memory map.

I think overlaying RAM, rather than ROM, allows the screen data to be read back from the copy in the existing RAM. This might be very useful for some software and is more consistent with the way computers of old did it.

My preference would be to recommend a default location for the dual port RAM to be something like 0xF000 to 0xF3FF, or perhaps as high as 0xF800 to 0xFBFF. My monitor uses the top of memory for workspace and stack, and I'm sure there is lots of other software that does the same. Similarly the bottom of memory has fixed uses for software, such as ROM BASIC. So both ends of memory should be avoided. However, it needs to be near one end or it breaks the continuous memory space assumed by most software. I think a strong recommendation for a default location is important for software support.

Ideally it would be nice to be able to software select where the dual port RAM sits in the memory map. With your current design this would cost lots of extra circuitry and not be very attractive. However, if your design allows for the Z80 to communicate in some way with the video controller, then perhaps this would be possible.

Also, if such communications is possible, you would have the means to do such things as define custom character sets. My first computer allowed characters to be defined as simple bitmaps and thus allowed some neat high resolution graphics.

With 1k of dual port RAM there may well be some bytes not used as video memory. For example, 40 characters x 25 lines is 1000 bytes, leaving 24 bytes free. Would it be possible to pass parameters through such unused locations?

If so, here are a few suggestions as to what to do with them:

* Select different resolutions

* Select a base address for the dual port RAM whereby the video controller outputs the 6 'address' lines to the comparator instead of using DIP switches. This would require 6 spare outputs from the video controller.

* Select between several built in character sets

* Define custom characters

Just my thoughts, but whatever you end up with I'm sure it will be a great addition to the RC2014 eco system.

Steve

[Jon Langseth]

My preference would be to recommend a default location for the dual port RAM to be something like 0xF000 to 0xF3FF, or perhaps as high as 0xF800 to 0xFBFF. My monitor uses the top of memory for workspace and stack, and I'm sure there is lots of other software that does the same. Similarly the bottom of memory has fixed uses for software, such as ROM BASIC. So both ends of memory should be avoided. However, it needs to be near one end or it breaks the continuous memory space assumed by most software. I think a strong recommendation for a default location is important for software support.

This problem of ROM + RAM for CP/M TPA being at Low addresses, and CP/M CCP/BDOS/BIOS + Monitor scratch space beinf at High addresses is what directed my design of a 16kByte window at "the third 16k" part of a 64k memory for the LiNC80 concept/design...

[StephenA]

Hi Jan/All,

My first post to this group. My RC2014 kit arrived some weeks back "Down
Under" but it is still resting on the bench. Patiently waiting
behind a couple of other unfinished projects. This post by Jan however has
prompted me to come out of "lurking" mode and introduce myself. Because
I've been actively thinking about this very same idea (design stage only)
and happen to have all the required parts to-hand.

Quickly, may I share a few of ideas.

I suspect that maximum flexibility comes by building a PropTerm board
similar to Marco's excellent looking PCB being discussed in another
thread.

https://www.tindie.com/products/maccasoft/vga-serial-terminal-for-rc2014/

(Personally I'd opt for a PS/2 keyboard interface rather than the USB one.
But that's just me)

This PropTerm board would interface via the serial lines on the RC2014 bus and
also needs to steal two spare lines to do proper hardware handshaking.
BTW: There are several similar PropTerm like projects out there but for sheer
VT100/ANSI completeness this one just blew me away:-

http://www.shaels.net/index.php/propterm

I'm happily using the above on a regular basis to connect to a telnet BBS from
a CP/M machine.

(I have not built or tried Marco's version)

Anyway, so far nothing much new here. We just have an excellent VT100/ANSI
terminal, generating VGA video with a local keyboard. So you can discard
the PC and use the RC2014 solo.

Now for the new ideas part...

What if we arrange a method by which the Z80 is able to re-program the
Propeller Chip?

For those not familiar with Propellers, when they power up after reset
they go looking for firmware to download via a serial protocol
on pins 39 & 40 of the Prop chip. The protocol is well documented. If it
can't find someone "talking" to it via these pins then it loads the
firmware from an attached EEPROM.

So by arranging for the Z80 to be able to download new and different
firmware on-the-fly you allow the PropTerm board to boot by default as
a VT100/ANSI terminal but you could rapidly re-load the firmware with another
terminal variant such as the Lear Siegler ADM-3A.
 
For this to happen we need to arrange that the Z80 can reset the Propeller
and then feed the new firmware in. This could be done by bit-bashing
from the system data bus. But my current thinking is that it may be easier
to just use the master terminal serial interface connected to pins 39 & 40
and latch one of the handshake lines (CTS/RTS) onto the Propellers reset pin
by some glue logic triggered by an IO call to a particular port.

Once you have a method by which the Z80 can re-load the Prop firmware on
the fly then you can also load Propeller software that does other
interesting things. Nothing stopping you from loading and running all
sorts of stand-alone Propeller applications/games (subject to hardware
constraints) but of course you can also load a video RAM graphics driver.

My thought was to place the dual-port video RAM chip on a separate board.
Cross connect the terminal PCB to the video RAM PCB with a top side
mini-video bus. Just a short length of ribbon cable with a couple of IDC
plugs. And we only need a few pins here, easily less than 16 I'd warrant.
Although Jan hasn't shared his ideas yet for the Propeller side interface
to the dual port RAM I'm guessing that it would be something along these
lines.

The Propeller chip needs to be able to pulse a binary counter which
provides the address for the dual port RAM. It should also be able to
reset the counter to zero. And in an ideal world it would be nice to load
the counter with a particular value from the Prop video data bus. The
eight bit bus between Prop chip and dual port RAM (not essential). So the
Prop needs something like 8 spare pins for video RAM data, 1 for pulsing
the binary counter, 1 for counter reset, 1 optional for direct counter
value load and possibly another to control propeller Write into video RAM.

Yes, I know that having the Prop able to Write to video RAM as well as
Read would create problems elsewhere. But if the video graphics driver is
to communicate things back to the software running on the Z80 (such as
Sprite collisions for example) then the obvious way to do this is via
shared video RAM. We would also probably need an additional pin on the
Prop for detecting RAM Write conflicts. So about ~12 to 13 Prop pins required
for this side of the circuit in addition to those required for the serial
terminal side.

Are there enough Prop pins available?

The Prop has 32 data pins (all data pins are equal on a Prop - meaning they can do any task).
A quick count shows we need about 16 pins for the VGA video terminal side of
things. So 'Yes' I think there are enough to go around. The main idea here being  
for the Prop to pulse loop the counter forever reading external
video RAM data 8 bits at a time into the Props internal Hub RAM (32K worth of
core hub RAM inside a Prop. So at a stretch you may even be able to allocate 16K
internally for graphics RAM).

With all this in place we can now load not just one video graphics driver
but many different ones supporting different video modes.

Since the combined terminal/video RAM board is still connected to the Z80
via the serial port it also allows for the creation of hybrid terminal applications.
Example: the original Sargon chess generates ASCII character graphics
to the serial terminal but a special Sargon video driver replaces the stock
terminal application and generates a high-resolution graphics for the
chess board pieces. Player keyboard interaction is fed back to the Sargon
software running on the Z80 by the same serial port.

Jan, your using a 1K dual port RAM chip. Perhaps we could upgrade
to 2Kx8?

They seem to be available in 1K, 2K and 4K. Not much difference in price
that I can see between 1K and 2K but a fair jump to 4K. The 2K at 2048
bytes happily accommodates a native 80x24 line video screen with some 128
bytes left over for passing control data back and forth. But of course
there is nothing to say that a video graphics driver would use video RAM
in such a simple 1:1 relationship (it does keep things simple though).

The reality is that this video RAM just needs to form a high speed
communications medium between the Z80 and Propeller. For just one "creative"
example of using very limited video RAM to generate resolutions higher
than one would expect just have a look at the Sinclair ZX80/81 encoding scheme.

Anyway, what was supposed to be a short post with a couple of ideas has now got out of hand 
and I've waffled on for far too long. So greetings to all and happy hacking!

I've leave you with a link to a demo program showing off the Propeller capabilities
both sound and video, from 2009 I think.

https://www.youtube.com/watch?v=6gEMKYnUADE

Steve

[Marco Maccaferri]

Il 16/05/2018 12:32, StephenA ha scritto:

> What if we arrange a method by which the Z80 is able to re-program
> the Propeller Chip?
>
> For those not familiar with Propellers, when they power up after
> reset they go looking for firmware to download via a serial protocol
> on pins 39 & 40 of the Prop chip. The protocol is well documented. If
> it can't find someone "talking" to it via these pins then it loads
> the firmware from an attached EEPROM.

No need for this as there is already a serial connection, it just needs
a protocol to safely upload the new firmware. That protocol could be
XMODEM as it doesn't require flow control, has CRC error check and
transmission can be "paused" the time needed to write the block to the
EEPROM. This is the next thing I would like to add to the firmware, I
need to find an escape sequence safe enough to start the file transfer,
don't know if more recent terminals have something that can be used.

> Once you have a method by which the Z80 can re-load the Prop firmware
> on the fly then you can also load Propeller software that does other
> interesting things. Nothing stopping you from loading and running
> all sorts of stand-alone Propeller applications/games (subject to
> hardware constraints) but of course you can also load a video RAM
> graphics driver.

Have you seen my other video card ?
https://github.com/maccasoft/propeller-graphics-card

That's specific for games and graphics, and already implements the
firmware update protocol that can not only write to the EEPROM but also
write to RAM only so applications can temporarily upload the firmware
they need and then reset back to the default.


Best regards,
Marco.

[David Brown]

I am a huge fan of your propeller graphics card.  I only wish you had routed the rx/tx pins to the unused propeller IO pins, so that the graphics card could also function as a terminal -- dynamically loading the appropriate propeller driver code when the functions are needed.  Or maybe using a larger serial EEPROM and having the propeller dynamically load the terminal code (like you do when the graphics card switches modes).

At any rate, great work there.

[StephenA]

No need for this as there is already a serial connection, it just needs
a protocol to safely upload the new firmware.

But then you have to waste valuable code space with the inclusion of your own up-loader code.

Why not just pulse the Prop reset pin and use the firmware up-loader already built-in for free?

 

That protocol could be
XMODEM as it doesn't require flow control, has CRC error check and
transmission can be "paused" the time needed to write the block

Caution. Xmodem protocol is simplistic Byte Checksum only. There is something called Xmodem-CRC.

Have you seen my other video card ?
https://github.com/maccasoft/propeller-graphics-card

That's specific for games and graphics, and already implements the
firmware update protocol that can not only write to the EEPROM but also
write to RAM only so applications can temporarily upload the firmware
they need and then reset back to the default.

Looks great, truly. But it has no serial connection. So you still end up with two cards. One for traditional CP/M serial terminal

communications and another for doing graphics.

I'm suggesting we can get away with only one card that does both tasks (although I grant you it becomes two cards once you out-board

the video RAM). This single card starts life on cold boot as a terminal but can magically become a video card on request.

No swapping VGA cables or turning off the second VGA monitor required.

[Marco Maccaferri]

Il 14/05/2018 18:57, Jan S ha scritto:

> Issues in general: If I "claim" one Kb of RAM out of the 64Kb space,
> I need to be able to "disable" ram on other bords while addressing
> the videoram. And none of the RAM/ROM or Combined RAM/ROM boards are
> constructed to handle this. So there's an issue that I need to handle
> anyway.

The posts from Spencer Owen and Shaun ONeil made me thinking that a
dual-ported ram is not really needed and there should not even needed to
make changes to the existing ram boards.

With some clever pin assignements I think the Propeller can "capture"
the memory writes to the video-ram addresses and save the data into the
internal hub ram for processing, this effectively writes to both the
Propeller ram and the standard Z80 ram, like a sort of mirrored write.
When you read from that addresses you just read from the Z80-visible
ram, the Propeller does nothing in that case, since the data is the
same. Of course this setup won't allow the Propeller to update the
Z80-visible ram locations.

This should allow the Z80 software to perform things like scrolling
(which requires to read the existing contents and write it to the new
locations) that would be impossible if the video ram is mapped to the
rom space or any other read-only location. CP/M needs to be modified to
reserve the video ram space (maybe just below the bios starting address).

What do you think ?

Best regards,
Marco.

[Jan S]

All :-)

There's been very good feedbacks from many of You on this "Memory mapped video interface". And thanks for that :-)
You've raised points, that I certainly will take into account when taking the next step.

My comments (in short):

I've got more than one reason to wrap this up on dual-port RAM.

1. Test procedures are a lot simpler, when the construction can be fired up as a two stage rocket. First stage is wiring port-A to work as ordinary RAM from the host CPU perspective. Second stage is extracting the data and display the result on a VGA (or other) screen.

2. Stealing bytes from right under the nose of any CPU is not allways that simple. I'll attach a schematic showing how this was done on my Nascom2. The chipcount is serious; but the learning potential on how to build and display a "screen" is sure present :-)

3. The RC2014 is not limited to Z80, but leaves opportunities for other CPU's. As interfacing different families af CPU's may vary from one to another, it felt simpler to keep these two interfaces separated (Read: The host CPU and the screen generating curcuits). In that way one could concentrate on interfacing a CPU of particular interest without trashing up the screen generating curcuits.
The dual-port RAM fells right for this purpose too :-)

4. And - in case I didn't mention it earlier - I've never worked with real dual-port RAM before, so it felt a little sexy to give i a shot ;-)

---------------

Note 1. ("on the fly" updateable propeller firmware)
I'll keep in mind that the Propeller has even greater potential, if "firmware" could be updated "on the fly" or directly communicated with; but that challange is not the first I'll concentrate on.

Note 2. (Updateable Alphanumeric/graphics ROM)
An updateable character matrix (either kept inside the Propeller or e.g. in an EEprom) is also something I'll keep in mind :-)

Note 3. (Old style B/W Video output)

Note 4. (Keyboard interface, ............)

Roadmap:

* Get the RAM side to work with the Z80.
* Verify that the RAM window is relocateable in steps of 1K
* Make the propeller create a screen output (any ASCII combination [test]).
* Make the propeller create the screen based on contents of the dual-port RAM.

/Jan

[Jan S]

All,
And, as promised, a revised schematic of the Nascom2 video generating interface.
IC50 is a 1K ordinary static RAM, that is reacable from both the CPU and the video generating curcuits.
/Jan

[Jon Langseth]

Looks great, truly. But it has no serial connection. So you still end up with two cards. One for traditional CP/M serial terminal

communications and another for doing graphics.

There seems to be a very wrong idea going round that CP/M console I/O is and has always been serial. That is nonsense. Even the Nascom, where much of our RC2014-related software has it's origins did CP/M with it's console on the on-board video interface.

It is a fact that the original CP/M sources used serial, as the original target hardware did not have video on-board. It is also true that the popular written-from-disassembled BDOS version from Clark Calkins, accompanied by the popular BIOS written by Grant Searle targets a serial console.

But that does not stop anyone from writing a BDOS/BIOS combination where the CRT: device is implemented via an actual video interface, with a memory mapped or even I/O register based design. That is how it was done! The Nascom, Kaypro, Osborne and CPC versions of CP/M did just that.....