User Experience Module - PS/2 & VGA

[Phillip Stevens]

For a while I've thought about using my RC2014 as full computer, with a full size keyboard and a proper monitor.

So, in the spirit of always learning, I've decided to build a "User Experience" UX Module for my RC2014.

The UX Module is based on a Parallax Propeller chip, and draws quite a lot from Marco's prior designs and will use the extensive Propeller code base available in their "object exchange".

I've tried to integrate an outcome that would take 3 Modules with Marco's designs into one single Module.

The design goals are to:

• Provide PS/2 Keyboard and VGA physical interfaces, so the RC2014 can be "stand alone".
• Emulate a ACIA or SIO serial device to provide a CONSOLE text mode video interface.
• Emulate a second ACIA or SIO TTY serial device on FTDI pin-out.
• Emulate a video device to enable 2D/3D vector graphics overlay (stretch goal).
• Emulate at least one sprite/tile mode for TMS9918 overlay (stretch goal).

Effectively it is an integration of Marco's projects (and with a Serial I/O Module) but using PS/2 for the keyboard (because it is easier).

I've added a 500mA power supply with timed Reset, because I'm intending to run the Propeller at 128MHz.

What it is not designed to do:

• Support PAL/NTSC video (we're past that).
• Support sound (other modules do that).
• Support mass storage (other Modules do that).
• Complete TMS9918 emulation (there's the real thing).

Of course the gotcha here is that I've totally no experience writing Propeller assembly language.

But in 2017 it was the same for Z80. How hard can it be?

So this is a bit of a meaty longer term project.

Anyway, the hardware design is now done, and I'm about to hit up Seeed to get a PCB Built.

If anyone wants a PCB to experiment (particularly if you're in Australia/NZ) let me know.

In Northern Hemisphere, if you're interested drop me a note and I'll send you the Gerbers.

Enjoy, Phillip

[Marco Maccaferri]

Il 24/09/20 04:54, Phillip Stevens ha scritto:

> The design goals are to:
>

> - Provide PS/2 Keyboard and VGA physical interfaces, so the RC2014 can
> be "stand alone".
> - Emulate a ACIA or SIO serial device to provide a CONSOLE text mode
> video interface.
> - Emulate a second ACIA or SIO TTY serial device on FTDI pin-out.
> - Emulate a video device to enable 2D/3D vector graphics overlay
> (stretch goal).
> - Emulate at least one sprite/tile mode for TMS9918 overlay (stretch
> goal).

Interesting project.

Don't know if you already seen that (don't remember if I have posted
something here):

https://www.maccasoft.com/electronics/vga-interface-for-rc2014-computer/

It is basically a VGA + ACIA emulation. It monitors only two ports but
with some changes I think it can monitor more ports.

I also have an almost complete TMS9918 emulation here:

https://github.com/maccasoft/propeller-graphics-card/tree/master/tms9918

Best regards,
Marco

[Phillip Stevens]

Marco Maccaferri wrote:

Hi Marco,

no I hadn't seen that you'd built the integrated version. What I've laid out is pretty much your integrated version, with some minor differences.

I wasn't happy with using your earlier versions, that would have required 3 slots to get the same outcome.

Seems you've had the same thoughts already. :-)

Hopefully, I'll be able to use your code to help me along with learning Propeller assembly.

I've changed a few minor things.

• Used A7, A6, (and A0) to allow major interfaces at 0x40 (video graphics mode), 0x80 (video serial text mode), and 0xC0 (tty second serial?).
• Preferred a PS/2 keyboard interface, because "retro" (I note you have both PS/2 and USB done).
• Pushed Tx/Rx interface back onto the bus.
• Connected /INT, so that the ACIA or SIO emulation can do IM1 / IM2 interrupts.
• Connected the VGA I2C interface, so that monitor info can be read (and possibly auto-adjust scanning).
• Used a 3v3 supply with integrated RESET delay.
• Removed the speaker to recover some I/O pins.
• Done the Tx/Rx to match FTDI pinout (rather than Propeller pinout).

I'm sure I'll have 100 questions, when I get along with this project.

Having your TMS9918 to copy will help immensely.

Have you done a "modern" vector graphics kind of interface previously?  I'm thinking something like the FTDI EVE FT800 graphics devices. That style of GPU is perfect to implement with the Propeller, as there is no frame store needed, but rather a vector instruction store that holds information so the scan line can be generated dynamically just before it is displayed.

Cheers, Phillip

[Marco Maccaferri]

Il 24/09/20 09:40, Phillip Stevens ha scritto:

> - Connected /INT, so that the ACIA or SIO emulation can do IM1 / IM2
> interrupts.

Not sure it can handle IM2, despite the fast clock, the instructions
requires 4 clock cycles and with all things to do it may not be fast
enough. At 80MHz it always need to assert the wait line to properly
present the data for an IN instruction, and it must be asserted very
quickly otherwise it will be sampled on the following instruction.

> - Removed the speaker to recover some I/O pins.

Audio can be done with one pin, if you manage to free one (maye IORQ
linked to the address lines ?), and there are emulators for AY3891,
SN76489 and even SID.

Hope it will not run out of cogs... :-)

Had only a quick look at the schematic and pcb, just a note: be sure to
have a bypass capacitor on both power pins otherwise the internal PLL
may be damaged.

> Have you done a "modern" vector graphics kind of interface previously? I'm
> thinking something like the FTDI EVE FT800 graphics devices. That style of
> GPU is perfect to implement with the Propeller, as there is no frame store
> needed, but rather a vector instruction store that holds information so the
> scan line can be generated dynamically just before it is displayed.

No, but this thread on the Parallax forum looks interesting.

http://forums.parallax.com/discussion/171856/wip-beam-chasing-polygon-rasterizer

Best regards,
Marco

[Phillip Stevens]

Marco Maccaferri wrote:

Il 24/09/20 09:40, Phillip Stevens ha scritto:

Had only a quick look at the schematic and pcb, just a note: be sure to
have a bypass capacitor on both power pins otherwise the internal PLL
may be damaged.

Marco, thanks. You must be reading my mind...

I spent 15 minutes (literally) looking at that capacitor, wondering whether it was needed, or not.

I was going to ask, but you've given me the answer already.

 

> Have you done a "modern" vector graphics kind of interface previously?  I'm
> thinking something like the FTDI EVE FT800 graphics devices. That style of
> GPU is perfect to implement with the Propeller, as there is no frame store
> needed, but rather a vector instruction store that holds information so the
> scan line can be generated dynamically just before it is displayed.

No, but this thread on the Parallax forum looks interesting.

http://forums.parallax.com/discussion/171856/wip-beam-chasing-polygon-rasterizer

Yes. That's exactly what I was thinking. Perhaps Wuerfel_21 has seen or used the FTDI EVE previously? But what he's done works just like EVE.

Thanks for the link.

The EVE has two display lists, the user writes to back list, and when the list is ready it is swapped for the front list. Rendering is done from the front list at frame rate.

Managing access to the two lists is just changing a pointer. Having two lists makes it easy to manage frame consistency, and enables slow CPUs to build a list using a high level GL without needing to do it within one frame time. The tenderer just reads the list, and generates an active set of pixels for the slice it is working on. With the propeller, it would be possible to share the front list rendering task amongst multiple cogs, and have just one cog managing the back list.

Anyway. Conjecture at the moment.

Cheers, Phillip

[Phillip Stevens]

Had only a quick look at the schematic and pcb, just a note: be sure to
have a bypass capacitor on both power pins otherwise the internal PLL
may be damaged.

Marco, thanks. You must be reading my mind...

I spent 15 minutes (literally) looking at that capacitor, wondering whether it was needed, or not.

I was going to ask, but you've given me the answer already.

Ok. Fixed that.

And, fixed another issue.

Just noted that the VGA I2C DDC/CI addressing conflicts with the EEPROM default addressing.

Since the EEPROM address (0xA0) is hardcoded into the Propeller ROM boot-loader, something needed to change.

So, I reversed the SDA/SCL pins into the VGA socket, and will have to accommodate that pin swap in my I2C driver later (which for the Propeller is no issue).

P.

[Chris Brunner]

This is fantastic! I was working on a similar design but you are way ahead of me.  I hadn't gotten near as far as you have.  I wanted to build a local console interface that could also do graphics for my SC126.  I was looking at essentially trying to combine the functionality of both of Marco's VGA boards (graphics and console) into one which seemed electrically possible but I wasn't sure about how to get the firmware to work. I'll be keeping an eye on this thread!

--
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/949658b7-f293-40bb-b35a-489b49f3941bo%40googlegroups.com.

[Michael Stevens]

Very interesting, I know the Propeller Chip, but actually more expensive as a single chip. I was going a different route with the ESP32 as a VGA Terminal using the FABGL library. 

Pie in the sky at present though. I see your work as being different, all interesting.

Regards

Mike.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CALc%3DYoO7ivc56gObnNdTyF-39R4kGACjM-0HKpBLfh%2BMeTZBhQ%40mail.gmail.com.

[Hans Hübner]

There is also Geoff's VT100 Terminal (https://github.com/petrohi/terminal) which works quite well.  It uses a somewhat exotic PIC32 microcontroller, though.

Before realising that there are so many terminal projects out there, I wrote some code running on a bare-metal Raspberry Pi to emulate a VT220.  The code is out there at https://github.com/hanshuebner/pivt and some people told me it works well for them.  The nice thing about the Pi is that it has enough horsepower and a real video interface to actually keep up with a fast serial port.  That can't be said about Geoff's VT100, and I found that to be an issue with the ESP32 based emulator as well.

-Hans

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CANDE_bm7FHQpv_6%3DCcAcobQdZZV2EkQxTKMCuYu66BkU%2BG0B7A%40mail.gmail.com.

[Chris Brunner]

Oooohhhh now that is a good idea too.  I have a couple nodemcus laying around.  I honestly forgot all about FABGL.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CANDE_bm7FHQpv_6%3DCcAcobQdZZV2EkQxTKMCuYu66BkU%2BG0B7A%40mail.gmail.com.

[Michael Stevens]

I suspect opens up more questions. If we need to go with the designed for RC2014, this board is more of a compatible, designed for my other usage.  Would be nice to hear the thoughts of Spencer on the use of "COMPATIBLE" We can see no need for the BUS Connection unless want to play Z80.

Not interested in stealing food from tables.

Regards

Mike,

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CALc%3DYoNxGJNDw3kztn6-150Lva8TLwABM%2BOXNVixAQzyhK%3DdSQ%40mail.gmail.com.

[Bill Shen]

It is good to see all the various  Z80 video/keyboard ideas in one thread.  I thought I'll also add my video/keyboard design to the list.

My design is a monochrome 56 rows x 80 column text display named VGARC (VGA for RC2014). https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:vgarc
It uses two 4Kx8 dual port RAM to store text and font table.  The video engine is based on a CPLD that generates the horizontal, vertical video timings, reads video text from the dual port RAM and looks up the corresponding font table to convert text to video bit stream.  The other side of the dual port RAM is accessible by Z80 independent of the video engine.  8K bytes of text and font are directly addressable as contiguous I/O addresses (using 16-bit I/O addressing mode).   Read and write access to the video text can occur anytime without affecting the quality of video display.  If needed, the fonts can be change on the fly, but most of time it is loaded once after reset.  Because access to each side of dual port can occur asynchronously and the dual port RAM have access time of 35nS, VGARC board can be accessed with zero wait from 7.37MHz to 22MHz and beyond.  VGARC has spare I/O pins to accommodate PS/2 keyboard, but that was never implemented.  Here is a YouTube video of Game of Life running on VGARC, https://www.youtube.com/watch?v=Bfs_Bu87qB8.  The program is quite small, about 500 bytes, because it operates directly on the video text memory without the need of a separate data buffer.  The video quality is not affected by the intensive Z80 read/write operations on the video data.

VGARC is not under active development, rather it is a stepping stone to my current all-in-one design called Z80ALL, https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:z80all:z80all_rev1  where Z80 is overclocked to VGA pixel clock of 25.175MHz and the display is downsized to 64 columns and 48 rows.  I have the PS/2 keyboard working and is currently working on BIOS to implement a simple set of escape sequences.
  Bill

[Phillip Stevens]

Following a short intermission, the UX Module has been assembled, and passed the smoke test and it also produced a "Hello World".

This means that the FTDI serial interface, I2C EEPROM, Oscillator, and 3V3 power supply are all working as expected.

The rest, as they say, is "just software".

Looking forward to getting my propeller hat on.

[n.hae...@gmail.com]

I'm wondering, will the VGA Serial Terminal Kit for RC2014 be re-issued on Tindie any time soon?

[karlab]

Phil, nice module!

I have several of Marco's terminal module which I am very pleased with.

What is the difference between your and Marco's module? 

The PS2 keyboard connector is obvious, but I am thinking more on the software part?

Karl

[Phillip Stevens]

karlab wrote:

Phil, nice module!

Thanks, Karl.

 

I have several of Marco's terminal module which I am very pleased with.

What is the difference between your and Marco's module? 

The PS2 keyboard connector is obvious, but I am thinking more on the software part?

Well the biggest difference is that his module actually has software, and it works.

Which is completely not the case for my module currently. ;-P

But if we're talking futures here... I've made a list of the hardware changes I made...

• Used A7, A6, (and A0) to allow major interfaces at 0x40 (video graphics mode), 0x80 (video serial high-res text mode), and 0xC0 (tty second serial?).
• Preferred a PS/2 keyboard interface, because "retro" (Marco has both PS/2 and USB done).
• Connected the keyboard/serial Tx/Rx interface back onto the bus.

• Connected /INT, so that the ACIA or SIO emulation can do IM1 / IM2 interrupts.

• Connected the VGA I2C interface, so that monitor DDC/CI info can be read (and possibly auto-adjust scanning to monitor capability).
• Used a 500ma 3v3 supply with integrated RESET delay.
• Removed the speaker.
• Done the Tx/Rx to match FTDI Basic pinout (rather than Propeller pinout).
• Set the base oscillator to 8MHz, so the Propeller Cogs run at 128MHz (rather than 80MHz).

Cheers, Phillip

[Marco Maccaferri]

Il 05/11/2020 11:36, n.hae...@gmail.com ha scritto:

> I'm wondering, will the VGA Serial Terminal Kit for RC2014 be
> re-issued on Tindie any time soon?

Guess this is for me :-)

None of my products will be available anytime soon, at least not until
the pandemic crisis gets better (a lot better).

Best regards,
Marco

[karlab]

Hi Marco

I understand, you have had a pretty rough time in Italy.

Is there any signs of improvement?

Karl

[Marco Maccaferri]

Il 05/11/2020 13:41, karlab ha scritto:

> I understand, you have had a pretty rough time in Italy. Is there any
> signs of improvement?

Nope. The government has issued new restrictive regulations starting
tomorrow, although not as hard as march-april. Luckily I'm in a zone
with a "moderate risk" without confinement rules, nevertheless I'll
limit the movements to the bare essentials anyway.

Best regards,
Marco

[n.hae...@gmail.com]

Hello Marco,

thank you for responding. I really hope we all will see some light at the end of this frightening pandemic soon ...

[Wayne Warthen]

You may find some useful code in the RetroComp PropIO V2 project found at https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:propio:start

This board is supported by RomWBW, but interfaces directlly via the bus (does not emulate ACIA, SIO, etc.).  Regardless, you will find some decent code for VT100 terminal emulation as well as screen and keyboard interface examples for the Propeller.

-Wayne

[Phillip Stevens]

Wayne Warthen wrote:

You may find some useful code in the RetroComp PropIO V2 project found at https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:propio:start

Thanks Wayne. I'll take a look.

Most interested to see how the Z80 bus is handled. I've some ideas, but it is always best to see how experts have done it first. 

This board is supported by RomWBW, but interfaces directlly via the bus (does not emulate ACIA, SIO, etc.).

I'm in two minds about this. I would like to have "drop in" compatibility for the standard software which implies ACIA emulation and a text mode.

But, on the other hand I'd like to have a capable graphics mode. Anyway graphics mode (sprite or vector based) is a stretch goal.

 

 Regardless, you will find some decent code for VT100 terminal emulation as well as screen and keyboard interface examples for the Propeller.

I've got to say that the Propellor "OBEX"  is already full of working examples for just about everything.

I've been able to test all the interfaces (except RC2014 bus), just by using existing code. Makes the Propeller "on-ramp" very smooth.

But having some more examples will be great.

P.

[Phillip Stevens]

Following a short intermission, the UX Module has been assembled, and passed the smoke test and it also produced a "Hello World".

This means that the FTDI serial interface, I2C EEPROM, Oscillator, and 3V3 power supply are all working as expected.

The rest, as they say, is "just software".

And with the examples from the Propeller OBEX (Object Exchange), I've been able to confirm that the PS/2 port and the VGA interface are working as expected.

This is 640x480 demo (squashed onto a shared screen with my workstation.

It is using the internal font stored as part of the system ROM, so there is no need to fill the user ROM with additional fonts.

I've got a VGA->HDMI adapter from Vention on AliExpress. It works as expected (which is lucky).

Because this first module was for testing, I left the resistors on the VGA outpu standing proud a little.

This makes hooking test probes easier.

Now, to take a step back and work out how these pieces will play nicely together.

P.

[Phillip Stevens]

Phillip Stevens wrote:

Following a short intermission, the UX Module has been assembled, and passed the smoke test and it also produced a "Hello World".

This means that the FTDI serial interface, I2C EEPROM, Oscillator, and 3V3 power supply are all working as expected.

The rest, as they say, is "just software".

Well "just software" couldn't have been further from the truth. But now the Z80 bus interface is working as expected, and the ACIA emulation is also working.

At the moment, I've just got the UX Module behaving as an ACIA Module. I'm still to integrate the VGA & PS/2 interfaces together, but that will happen soon.

I've started a Github Repository for the UX Module.

So, what did I learn?

1. The Parallax Propeller doesn't work perfectly at 128MHz. Reading the data sheet it is not totally clear that it won't work, and there is a specification for the system PLL multiplier working up to 8MHz (with 16x multiple). The "normal" oscillator is 5MHz, resulting in a supported 80MHz system clock. In the end I've used the RC2014 standard frequency of 7.3728MHz, resulting in a system clock just short of 118MHz. Given this system is working in "best case" with correct supply regulation, at room temperature, there seems to be no problem with this overclock. But selecting a 6.25MHz or 5MHz oscillator is also an option for those who like to play safe.

2. The standard bus interconnect method suggested to connect the 3v3 Propeller to a 5v bus is using 4k7 ohm serial resistors. Whilst this works for most applications, sensing fast transitions on a Z80 bus requires a better solution. Following a bit of reading and advice, I've implemented 1nf serial capacitors (in parallel to the current limiting resistors). This produces much better waveforms which the Propeller can use as triggers. I've also reduced the resistance value to 3k3, which is appropriate where the supply voltages are well known as they are here.

This is the IORQ lead on the bus side (blue) and on the Propeller side (yellow), before I added in the capacitors. Over 100ns is required before the level decays sufficiently to trigger a low level at 3v3.

On a Z80 bus one does not have 100ns to waste.

This is the same IORQ lead following addition of the 1nf capacitor. Yep. looks much better.

3. Propeller Assembly is quite fun. It has a very flexible "Effects" capability, where Zero Flag and Carry Flag can optionally written on any instruction, and then that result remains valid until you choose to overwrite it. Also any instruction can optionally be conditional on the flag result. This avoids the need to branch for two or three instructions; simply make those instructions all conditional on the same flag result, and then they will not be excuted (or rather are executed as nop) if the flag not correct.

Thanks again to Marco for helping out on all of these issues.

4. A Z80 learning. Where I thought that the /INT pin required a level to be recognised, in fact (RTFM) it needs only a pulse. Getting to that fact took me far too long.

So I've done a revision of the PCB. There are two major changes. Firstly, adding serial capacitors on all the relevant control lines. And second, using a 74HC4078 NOR gate to provide address discrimination. Similar to above, because of the timing requirements, the standard diode wired OR gate isn't fast enough. The only way to get the diode wired OR solution to operate fast enough is to load it with 1k ohm pulling to ground, and that is too much of a load for my liking.

Making this changed also freed a Propeller IO Pin, so I've connected the Z80 /RESET. This will enable the user to reboot the RC2014 using the keyboard (think CTRL+ALT+DEL). It will also be possible to build a watchdog process running on the UX Module to check for activity and if needed reboot first the RC2014, and then the UX Module all under software control.

I've decided to use "big" SMD 0805 devices for the Z80 bus interface. Only two SMD components are required. 3k3 Ohm resistors, and 1nf capacitors. To make assembly easy, I've put all the resistors on the front of the PCB, and all the capacitors on the back of the PCB. This should make the UX Module a very good project for anyone keen to have a go at using SMD for the first time. The capacitors are all directly under the resistors, so are difficult to see from the front.

More when all the software pieces are working nicely.

Cheers, Phillip

[Colin MacArthur]

Very NICE looking board...

You may want to look at Wayne's (RomWBW) ECB PROPIO board for some inspiration...

https://www.retrobrewcomputers.org/doku.php?id=boards:ecb:propio:start&s[]=propio 

I have been able to use his rebuild his board for the RC2014 and his firmware works GREAT

(RomWBW\Source\Prop see attached) giving you a VGA / Keyboard / SD drive...

GOOD LUCK...

CM

[Colin MacArthur]

You may want to check out the !WAIT circuit on Wayne's board. I believe it was added because the PROP could not respond fast enough...

(Wayne please correct me if I am wrong)...

CM

[Wayne Warthen]

On Mon, Nov 23, 2020 at 8:54 AM Colin MacArthur <c...@cm.ca> wrote:

You may want to check out the !WAIT circuit on Wayne's board. I believe it was added because the PROP could not respond fast enough...

(Wayne please correct me if I am wrong)...

Colin, you are correct.  The PropIO v1 did not have the !WAIT circuit and could only handle CPU speeds of about 6MHz.  The new !WAIT circuit (on PropIO v2) is effective up to about 16MHz in my testing.

-Wayne

[Phillip Stevens]

Colin wrote:

You may want to check out the !WAIT circuit on Wayne's board. I believe it was added because the PROP could not respond fast enough...

(Wayne please correct me if I am wrong)...

Wayne wrote: 

Colin, you are correct.  The PropIO v1 did not have the !WAIT circuit and could only handle CPU speeds of about 6MHz.  The new !WAIT circuit (on PropIO v2) is effective up to about 16MHz in my testing.

Colin, Wayne, thanks for reading along and input. :-)

Yes, the /WAIT circuit is an essential part of the design. Marco also uses a /WAIT circuit as part of his VGA Modules, and I've referenced his code too.

The Propeller is unique (correct me if I'm wrong please), in that it can programatically respond to programmed set of pin changes within 6 clock cycles, and that it is available in an old school 40 pin DIP.

For me that generates a /WAIT in just 50ns theoretically (and I've measured 41ns practically).

I think that the Z80 /WAIT has to be generated after the /IORQ in no more than 1.5 clocks minus a small amount. Let's go with one clock cycle to be safe.

So with with a 41ns /WAIT response, this solution should be good up to around a 20MHz Z80 system bus. Certainly safe at our RC2014 standard bus.

The PROPIO code uses the WAITPEQ instruction to check for IO states.  This is the Propeller's secret weapon to manage IO really fast. Essentially you pend a "cog" until a set of pins (programmatically masked) match a state you programatically determine. This way the cog can respond instantly to an "interrupt" generated by a multi-pin state you prefer. But, the PROPIO code doesn't use the WR Effect with WAITPEQ, from what I read.

Marco has taken this one step further with his VGA Module code, and used a documented side effect of the WAITPEQ instruction to also trigger the /WAIT line IN THE SAME INSTRUCTION.

By using the OUTA register (controlling the IO pin value) as the comparison with the input registers, and the WR Effect the /WAIT pin gets toggled on match.

I've used the same software mechanism to get to the 6 cycle result, too.

Anyway, there's a whole thread on using WAITPEQ with WR Effect on the Propeller Forum if you're interested to read deeper.

After I get the basic functionality done, I'll offer the PCB on Tindie. And an option with the SMD done too.

It is too hard for me to sell complete kits on Tindie, as the postage from Australia is exorbitant. But a PCB can be slipped into a regular envelope with no worries.

Drop me a note if you'd like the Eagle brd/sch files in the interim.

Cheers, Phillip

[Wayne Warthen]

On Monday, November 23, 2020 at 4:19:36 PM UTC-8 Phillip Stevens wrote:

I think that the Z80 /WAIT has to be generated after the /IORQ in no more than 1.5 clocks minus a small amount. Let's go with one clock cycle to be safe.

So with with a 41ns /WAIT response, this solution should be good up to around a 20MHz Z80 system bus. Certainly safe at our RC2014 standard bus.

Yes, this sounds right.  However, the dediated /WAIT circuit in PropIO should be quite fast and it seems to fail somewhere between 16-20 MHz.  That always surprised me and I couldn't explain it.

The PROPIO code uses the WAITPEQ instruction to check for IO states.  This is the Propeller's secret weapon to manage IO really fast. Essentially you pend a "cog" until a set of pins (programmatically masked) match a state you programatically determine. This way the cog can respond instantly to an "interrupt" generated by a multi-pin state you prefer. But, the PROPIO code doesn't use the WR Effect with WAITPEQ, from what I read.

I was not aware if tge /WR effect trick.  I'm interested to see how well that works.  Certainly sounds good.

-Wayne

[Colin MacArthur]

You may be on to something...

I hope it works as it would reduce the part count & board size...

Keep us posted

THX

CM

[Phillip Stevens]

Colin wrote:

You may be on to something...

I hope it works as it would reduce the part count & board size...

Keep us posted

I've uploaded a video of the "end result". UX Module Initial Video.

Note the PS/2 keyboard is not connected here, but It has been working in other tests.

All the pieces are working properly now. The VGA Interface, PS/2 Interface, and Serial Interfaces are all based on library code, so there's nothing the prove there.

The issue has been the ACIA Z80 emulation, and getting that to work has been the topic of interest.

It is important for me that it be a proper ACIA Emulation, so that the UX Module doesn't need any software on the Z80 side, and all the standard ROMs will just work.

And, that seems to be the case, as seen in the video.

All that remains now is the "grind" of connecting all the VT100 Terminal Control into the VGA Screen Control, and ensuring that the PS/2 Keyboard is passing correct characters for specific key strokes.

 

Marco has taken this one step further with his VGA Module code, and used a documented side effect of the WAITPEQ instruction to also trigger the /WAIT line IN THE SAME INSTRUCTION.

By using the OUTA register (controlling the IO pin value) as the comparison with the input registers, and the WR Effect the /WAIT pin gets toggled on match.

I've used the same software mechanism to get to the 6 cycle result, too.

Anyway, there's a whole thread on using WAITPEQ with WR Effect on the Propeller Forum if you're interested to read deeper.

The PROPIO v2 board uses a hardware /WAIT trigger, so there's nothing to be gained from WAITPEQ with WR Effect.

But if you're interested in redesigning it to reduce the component count, then the software solution has now been proven by both Marco and me independently, so I think it can be trusted as an option.

Cheers, Phillip

[Phillip Stevens]

I've joined enough dots now to get the PS/2 keyboard and VGA screen working with the RC2014.

 Click here for a short video of the UX Module working with RC2014 MS Basic.

RC2014 with the cords cut (so to say).

Please excuse the slow coding. Basic is not my first language.

It is good to have this all working.

Github UX Module Repository here.

Cheers, Phillip

[Phillip Stevens]

Done another iteration on the UX Module PCB.

The major changes are

•  using large 0805 SMD for some of the resistors and capacitors (hidden on the back of the PCB) - makes the layout less messy.
•  using a 74HC4078 NOR gate to capture all of the low address lines and /IORQ into one Propeller input pin, unloads the address bus (compared to diode logic).
•  using one freed input pin for the Z80 reset, to allow the UX Module to restart the Z80 (CTRL-ALT-DEL from keyboard).

Everything else is the same, and works as expected as a ACIA Serial Module drop-in substitute.

I'm using a Vention VGA-HDMI converter. They cost about $8, and do the job excellently.

https://www.aliexpress.com/item/4000099169235.html

https://www.vention.cn/product/vga-to-hdmi-converter/

 

Github UX Module Repository here.

The current code is really rudimentary. Marco supports multiple keyboard layouts and traps all of the different key combinations for VT100 graphics.

Currently I haven't gotten anywhere near that level of sophistication. Perhaps, one day.

Cheers, Phillip

[djrm]

Hi Philip,

Lovely board and its coming along nicely.

I like the design choices especially the ACIA emulation.

I need to make one.

David.

[Phillip Stevens]

Phillip Stevens wrote:

I'm using a Vention VGA-HDMI converter. They cost about $8, and do the job excellently.

WRONG://www.aliexpress.com/item/4000099169235.html

https://www.vention.cn/product/vga-to-hdmi-converter/

Of course I linked the wrong converter direction. Doh.

This Vention VGA->HDMI is the right one.

https://www.aliexpress.com/item/32844619223.html

Or, of course, you can use a real VGA monitor.

 

[Phillip Stevens]

Phillip Stevens wrote:

Done another iteration on the UX Module PCB.

The major changes are

•  using large 0805 SMD for some of the resistors and capacitors (hidden on the back of the PCB) - makes the layout less messy.
•  using a 74HC4078 NOR gate to capture all of the low address lines and /IORQ into one Propeller input pin, unloads the address bus (compared to diode logic).
•  using one freed input pin for the Z80 reset, to allow the UX Module to restart the Z80 (CTRL-ALT-DEL from keyboard). 

Github UX Module Repository here.

I finished testing on a "small" MS Basic (Classic) RC2014 and moved on to testing with a larger CP/M based system. And uncovered a few more issues.

Firstly, I initially selected 1nf capacitors for the control lines. These are too large and loaded up the control lines too much. I've since reduced them to 200pf, and perhaps will drop even further before finishing. The waveforms still look good with 200nf, so it would be possible to go even lower value.

I found an issue with the /WAIT line not working properly with the APU Module. Reading further discussions it would be good to entirely remove capacitance from the three Propeller output lines (/RESET, /INT, and /WAIT). I've now got some "digital" transistors to experiment with. These digital transistors are pre-biased (on substrate). This keeps the component count low, as the bias resistors are integrated into the package. They act as open collector inverter gates, so I'll need to reconfigure the bus software to suit. To be continued.

And finally, I've found that the resistor only solution for the data bus is quite slow with respect to the Z80 bus.

I'm resolving the issue now by putting one or more nop instructions in the code to allow the bus to settle after writing, but I feel the better answer would be to use parallel capacitance too.

But, that means 8 additional components to weigh against just adding one or two nop instructions. Decisions... decisions... decisions.

Here are the traces. Both traces are of the D7 line. Blue (2) on the Bus side of the bus resistor. Yellow (1) on the UX Module side of the bus resistor.

The Trigger point is the UX Module releasing /WAIT. And the centre of the screen is the /RD line being raised, 176ns after /WAIT is being raised.

  

Normally, the Z80 controls the data bus, so the UX Module (1) tracks the Bus (2).

But, in the zoomed-in trace the UX Module takes control of the bus slightly before it releases the /WAIT. This shows the data line rises to just 2V when it is sampled.

The code is here. If the bus is more loaded, then the rise time may be extended leading to errors, and this is what I noticed happening in practice.

 

So the question is nop or capacitors?

Phillip

[Phillip Stevens]

Phillip Stevens wrote:

Done another iteration on the UX Module PCB.

Github UX Module Repository here.

I finished testing on a "small" MS Basic (Classic) RC2014 and moved on to testing with a larger CP/M based system. And uncovered a few more issues.

Firstly, I initially selected 1nf capacitors for the control lines. These are too large and loaded up the control lines too much. I've since reduced them to 200pf, and perhaps will drop even further before finishing. The waveforms still look good with 200nf, so it would be possible to go even lower value.

Here I've found that 100pf in parallel with 3k3 ohms provides the best input waveforms. The edges are sharp, with very little overshoot. So all the input lines are now so designed.

 

I found an issue with the /WAIT line not working properly with the APU Module. Reading further discussions it would be good to entirely remove capacitance from the three Propeller output lines (/RESET, /INT, and /WAIT). I've now got some "digital" transistors to experiment with. These digital transistors are pre-biased (on substrate). This keeps the component count low, as the bias resistors are integrated into the package. They act as open collector inverter gates, so I'll need to reconfigure the bus software to suit. To be continued.

After a long circle around with digital transistors, I've returned to using open collector diode outputs in parallel with 200pf capacitance.

The learning was that the transistor logic was quite slow, adding up to 1000ns onto the length of the /WAIT hold (typically 240ns).

So that is not a good solution for this application.

Using the diode logic provides a sharp low transition, and 200pf of parallel capacitance kicks the signal enough to register a high level as soon as the /WAIT line is released.

This much smaller amount of capacitance doesn't impact the APU Module /WAIT usage (compared to 1nf previously).

And finally, I've found that the resistor only solution for the data bus pins is quite slow with respect to the Z80 bus.

I'm resolving the issue now by putting one or more nop instructions in the code to allow the bus to settle after writing, but I feel the better answer would be to use parallel capacitance too.

But, that means 8 additional components to weigh against just adding one or two nop instructions. Decisions... decisions... decisions.

Here it was possible to slightly reorganise the code to allow the data lines to settle whilst doing something useful. So it became obvious to continue to not use capacitors unnecessarily. 

So the final design is now "finished" as far as I'm concerned. In the end, the only substantial changes were:

• converting the /RESET line to diode + capacitor logic.
• pulling up the RX line to avoid noise when the FTDI interface is unplugged.
• adjusting the input/output capacitance.

Since this design is very close to previously, I can press on with polishing the code over the Christmas break.

(Drop me a note if you'd like the Gerbers).

Merry Christmas, Phillip

 

[Phillip Stevens]

So the final design is now "finished" as far as I'm concerned. In the end, the only substantial changes were:

• converting the /RESET line to diode + capacitor logic.
• pulling up the RX line to avoid noise when the FTDI interface is unplugged.
• adjusting the input/output capacitance.

Merry Christmas, Phillip

I've put the Christmas release UX Module PCBs on Tindie now.

There are two options, with SMD soldered and including 74HC7048, and as a base for the PCB only.

I made a short video showing how I solder the 0805 size SMD devices. It might be entertaining for those who actually know what they're doing.

But, that's the technique that works for me.

Still working on the software, but it is good as a baseline now. In text mode only at this stage.

UX Module on Github.

Finished outcome below.

[Chris Brunner]

That's exciting!  I have a couple questions though:

1) Is the firmware complete? Does it come pre-flashed?

2) I don't see the boards on Tindie. Is that link correct?

--
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/730d219a-7c62-4866-b9fb-a96793310200n%40googlegroups.com.

[Phillip Stevens]

Cyrus wrote:

That's exciting!  I have a couple questions though:

1) Is the firmware complete? Does it come pre-flashed?

I had only planned on selling the PCBs. But I get that SMD might be a challenge, so I’ve made that an option. Together with the 74HC7048 device, which is a bit hard to source. 

The Board supports either 256kb or 512kb flash for the Propeller. It has a boot loader that does the programming. And I recommend the Propeller IDE to program it. It is super easy to flash using the FTDI serial port.

  

I expect lots of options for the display firmware to develop. So you’ll want to choose your preferred screen resolution and key mapping etc. Also I hope that we can get vector graphics running too. Then you can mix your own preferences.

2) I don't see the boards on Tindie. Is that link correct?

They’re slow to approve, it seems.

Should be up soon. Sorry.

Cheers Phillip

[Chris Brunner]

No worries! And good work!  Yeah, admittedly I'm not really set up to solder SMD. I could probably do it by hand, but these damn hand tremors make it difficult. I do much better with THT. I'll most certainly be ordering the boards with the SMDs already soldered.

--

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/61498829-745f-432e-9427-71ab1eadb156n%40googlegroups.com.

[Wuerfel21]

Also I hope that we can get vector graphics running too. 

I think I can jump in to help with that whole graphics business once the text stuff fully works. 

[Phillip Stevens]

Finally dragged myself out of "2077" long enough to add to the documentation for the UX Module.

Added a BOM, usage instructions, and programming tips.

And I might start noodling on the text mode code again soon, too.

Cheers, Phillip

 

I've put the Christmas release UX Module PCBs on Tindie now. There are two options, 1. with SMD soldered and including 74HC7048, or just the 74HC7048. The base for the PCB only.

[Phillip Stevens]

Phillip Stevens wrote:

Finally added to the documentation for the UX Module.

Added a BOM, usage instructions, and programming tips.

I've put the Christmas release UX Module PCBs on Tindie now. There are two options, 1. with SMD soldered and including 74HC7048, or just the 74HC7048. The base for the PCB only.

So I’m having trouble with a seemingly irresolvable issue (through software).

The Propeller has an inbuilt ROM boot loader, that is initialised following a reboot, to check for uploading of new code. For convenience the serial interface (FTDI) DTR line is connected to the Propeller RESET line. This works great for development, as iterations of the firmware can be uploaded to the UX Module just by clicking a button on the Propeller IDE.

The problem is that the DTR line is managed by Linux and Windows in different ways. It seems impossible to open a serial port within Linux without having the DTR line toggle. This means that uploading BASIC programs using cat will trigger the UX Module to reboot. Not a desired outcome at all.

In Windows the situation doesn’t seem much better. The DTR line seems to be held low by Teraterm (for example) permanently, which means that the UX Module is held permanently in reset.

Looking around the ‘net people in the Arduino community have been seeking a resolution to this issue for years. There are some suggestions, but I can’t make them work. This means that an OOB Arduino can’t be unplugged from the USB interface, because it will reboot when the USB interface is enumerated (and DTF is toggled). Seeed / Sparkfun and others simply equip a switch to disconnect DTR.

And so it seems the only workable solution seems to be add a hardware switch to disconnect the DTR line for normal use. This means a new PCB. Most annoying.

Phillip

[Clark Martin]

You could cut a trace and mount either a switch or jumper. Which ever you choose you could mount either side.

[Phillip Stevens]

You could cut a trace and mount either a switch or jumper. 

> And so it seems the only workable solution seems to be add a hardware switch to disconnect the DTR line for normal use.

Even easier, an my interim solution is just to bend the DTR pin out a little so it doesn't insert into the FTDI Basic socket.

But it still means a new PCB, and the waste bin for the current design PCBs (of which I have quite a few).

:-(

[Marco Maccaferri]

Il 07/02/21 12:56, Phillip Stevens ha scritto:

> Even easier, an my interim solution is just to bend the DTR pin out
> a little so it doesn't insert into the FTDI Basic socket. But it
> still means a new PCB, and the waste bin for the current design PCBs
> (of which I have quite a few). :-(

As I wrote on the Parallax forum, the stty solution works for me:

/bin/stty -F /dev/ttyUSB0 -hupcl

The programs accessing the serial can still toggle DTR on their own, but
at least this disables the automatic toggle. Wondering why doesn't work
for you.

Using Ubuntu 20.10.

Best regards,
marco

[Phillip Stevens]

Marco wrote:

As I wrote on the Parallax forum, the stty solution works for me:
/bin/stty -F /dev/ttyUSB0 -hupcl

The programs accessing the serial can still toggle DTR on their own, but at least this disables the automatic toggle. Wondering why doesn't work for you.

I sure wish I knew why it doesn't work for me, too.

Anyway, I've posted a simple physical fix to my errata and I'm going to close it there.

Ideally the hupcl option will work for most people, and for the others it is just a matter of bending the DTR pin.

[Phillip Stevens]

I've added a new video showing the VGA+PS/2 being echoed by the serial terminal.

And also more interestingly -> being able to quickly upload BASIC programs to the RC2014 from another serial terminal.

UX Module Serial Operation

I'm getting a bit bored with the AUTUMN THEME. Next video might be in APPLE2 THEME.

p.

[Phillip Stevens]

Over the past few days I've been digging into usage with RomWBW.

And, TLDR, the UX Module works as expected. So that's good news.

But, there were some bumps in the road.

Firstly, the RomWBW stable v3.0.1 release uses a method to detect the ACIA device that relies on the particular build for the RC2014 ACIA Module, which is not compatible with the UX Module. The RomWBW 3.1.1-pre code in the dev branch fixed this issue some time ago by changing the detection method to rely on ACIA device characteristics alone (and not how the Module is implemented). So, we need to use the dev branch for this to work.

Ideally, we'd like to have a few serial ports available on our RomWBW RC2014, so we'd like to use a SIO Module as well. When doing this it is important to remember that both UX Module and SIO Module drive the backplane Tx/Rx pins, and there can't be two owners. So the best thing to do is just straighten the Tx/Rx pin headers on the UX Module so that they don't insert into the backplane (but can be bent back if/when needed).

Also, to prevent address conflict with the SIO at 0x80, we want to have the UX Module set to address 0x40.

Because of the way that RomWBW detects serial devices, the SIO ports will be detected first, causing them to become Char 0 and Char 1. As Char 0 is the boot console, nothing is going to appear on the VGA screen console. So, we need to rearrange the detection to ensure the UX Module (detected as ACIA) is forced to be the console port. This is done with the (as yet undocumented) FORCECON configuration. Assuming we have one SIO Module with 2 ports discovered before the UX Module ACIA port we want FORCECON set to 2.

An example from the configuration file looks like this.

UARTENABLE .SET FALSE ; UART: DISABLE 8250/16550-LIKE SERIAL DRIVER (UART.ASM)

;

ACIAENABLE .SET TRUE ; ACIA: ENABLE MOTOROLA 6850 ACIA DRIVER (ACIA.ASM)

ACIA0BASE .SET $40 ; ACIA 0: REGISTERS BASE ADDR

;

SIOENABLE .SET TRUE ; SIO: ENABLE ZILOG SIO SERIAL DRIVER (SIO.ASM)

SIOCNT .SET 1 ; SIO: NUMBER OF CHIPS TO DETECT (1-2), 2 CHANNELS PER CHIP

;

TMSENABLE .SET FALSE ; TMS: DISABLE TMS9918 VIDEO/KBD DRIVER (TMS.ASM)

;

FORCECON .SET 2 ; SET ACIA AS CONSOLE, ASSUMING 1 SIO MODULE CONFIGURED WITH 2 CHANNELS

Cheers, Phillip

[Wayne Warthen]

On Wednesday, February 10, 2021 at 10:14:34 PM UTC-8 Phillip Stevens wrote:

Because of the way that RomWBW detects serial devices, the SIO ports will be detected first, causing them to become Char 0 and Char 1. As Char 0 is the boot console, nothing is going to appear on the VGA screen console. So, we need to rearrange the detection to ensure the UX Module (detected as ACIA) is forced to be the console port. This is done with the (as yet undocumented) FORCECON configuration. Assuming we have one SIO Module with 2 ports discovered before the UX Module ACIA port we want FORCECON set to 2.

The most recent update to RomWBW in the GitHub dev branch has a bit of a cleanup with respect to the FORCECON setting.  The underlying mechanism for setting the boot console device has been simplified and a "proper" configuration variable is now available.

Previously, you would have used a line like:

FORCECON .SET 2 ; SET ACIA AS CONSOLE, ASSUMING 1 SIO MODULE CONFIGURED WITH 2 CHANNELS

This needs to be changed to:

BOOTCON .EQU 0 ; BOOT CONSOLE DEVICE

Sorry for the trouble.

Thanks,

Wayne

[Phillip Stevens]

Phillip wrote:

Assuming we have one SIO Module with 2 ports discovered before the UX Module ACIA port we want FORCECON set to 2.

Wayne wrote: 

The most recent update to RomWBW in the GitHub dev branch has a bit of a cleanup with respect to the FORCECON setting.  The underlying mechanism for setting the boot console device has been simplified and a "proper" configuration variable is now available.

This needs to be changed to:

BOOTCON .EQU 0 ; BOOT CONSOLE DEVICE

No problem. I agree this is a better way to define the boot console, by simply numbering off the preferred console.

In other news, an early release video of VECTOR Graphics (VJET) on the UX Module, all thanks to Wuerfel_21 (of SPIN HEXAGON fame).

Next step is to create a Z80 GL to make it easy to use on RC2014.

Wooo! Triangles! youtu.be/eN1TrmOITD8

Phillip

[Wayne Warthen]

Oops.  My example is wrong.  It should have be:

BOOTCON .SET 2 ; BOOT CONSOLE DEVICE

Notice I used ".SET" instead of ".EQU".

Thanks,

Wayne

[Wayne Warthen]

On Wednesday, March 3, 2021 at 4:56:09 PM UTC-8 Phillip Stevens wrote:

In other news, an early release video of VECTOR Graphics (VJET) on the UX Module, all thanks to Wuerfel_21 (of SPIN HEXAGON fame).

Next step is to create a Z80 GL to make it easy to use on RC2014.

Wooo! Triangles! youtu.be/eN1TrmOITD8

Nice! 

[Phillip Stevens]

It is hard to top the success that Wuerfel_21 had with the Spinning Triangles, but let's give it a go...

Over the past few days I've been working on implementing VT100 terminal control codes for the VGA screen, with the object of getting MiguelVis TE CP/M text editor to work (just like it does on the serial VT100 terminal). And, I think now I'm 99.9% there. So that goal is done.

Unfortunately, it isn't possible to implement all the full colour control options from VT100 as it is only a 4 colour high resolution text VGA driver.

Full 64 colour mode will be limited to the VJET Graphics mode in 256x240 resolution.

I've also done a little filtering for the XMODEM Tx direction. That means that when the Z80 is sending XMODEM packets, the packet contents won't appear on the screen. This helps to keep the display looking nice and aligned with a FTDI USB serial terminal that may be concurrently receiving and processing the XMODEM packets.

Since this is all done in Propeller SPIN, it is easy to update and maintain. The code is all in the readZ80 function,  which processes (filters) bytes received by the ACIA emulation, and forwards them to both the terminal emulation (FTDI USB), and the screen emulation (VGA terminal services) where relevant.

I should do another video, then its easy to see the outcome.

Cheers, Phillip

[Phillip Stevens]

Just to update, I've just replenished the stock of UX Module PCBs (after being sold out for a while), and they are now available on Tindie.

Over the past years there are now quite a few new options to get a VGA and PS/2 interface on your RC2014, including the RP2024 VGA Terminal and Pi Pico VGA Terminal, so why would you want a UX Module?

The main difference, from the perspective of the RC2014, is that it emulates the standard ACIA (MC6850) Serial Interface rather than connecting to the Rx/Tx pins on the backplane. The emulation is an interesting programming exercise in multi-core "cog" processing, and even so the timing required to emulate MC6850 "hardware" requires use of the Z80 /WAIT pin to keep up.

Also, it uses a Parallax Propeller to provide the video and keyboard interfaces. The Propeller is fully programmable and can be updated with further capabilities as you like. I'd encourage anyone using it to clone the github repository, and then build their own software configuration (for example screen colours, screen resolution, key mappings, etc) using the Propeller IDE for development. The Propeller IDE is available for all platforms (Windows, MacOS, Linux), and is an integrated editor, compiler, and ROM programming tool. There are other tools (eg. OpenSpin, PropellerGCC C) but the Propeller IDE is a good cross platform known working environment, that I like.

The UX Module also has a FTDI standard serial interface, used for programming the Parallax Propeller MCU rather than the Prop Plug interface found on most Propeller based PCBs. This serial interface can also be used for operating the RC2014, simultaneously with the VGA + PS/2 interface.

The UX Module can also be used as a stand-alone Parallax Propeller MCU module, with most of the bus pins brought out to a RC2014 style bus interface, opening the door to program other applications either within the RC2014 environment or completely independent of the RC2014.

Finally, the UX Module has very simple SMD devices and can be a training project for your first SMD soldering. There are passive components in 0805 size which are about the easiest place to start with SMD, and they can be soldered with a standard fine tipped soldering iron without trouble.

Phillip

On Monday 15 March 2021, Phillip Stevens wrote:

It is hard to top the success that Wuerfel_21 had with the Spinning Triangles, but let's give it a go...

Over the past few days I've been working on implementing VT100 terminal control codes for the VGA screen, with the object of getting MiguelVis TE CP/M text editor to work (just like it does on the serial VT100 terminal). And, I think now I'm 99.9% there. So that goal is done.