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