Some help needed with Bill Shen's ZRC512 SBC / RC2014 board

[Paul dB]

For those not yet familiar with Bill's new board, here's a short description.

It's a snappy, (mostly) through-hole, 22MHz Z80 SBC that can also be
used as a module together with other boards on an RC2014 or RCBus
backplane. Only the solder tabs on the CR1220 battery holder (for the RTC)
need soldering on the back of the board. The board also has an I2C
interface and a through-hole LED-type WS2812B (NeoPixel) interface. This
is all on a 2"x4" 4-layer PCB.

I used the RomWBW binary image Bill provided on the ZRC512 homepage to
flash a CF card. Apart from some start-up code in the CPLD, the ZRC512 is
ROM-less and boots directly from a CF card.

With the CF card in place, powering up the board by itself (as an SBC),
it boots into the Bill's ZRC512 Monitor. Then typing 'b4' it boots into
'RomWBW-v3.4.0-dev.9'. Finally, typing in 'c' in RomWBW it boots CP/M 2.2.

I've also used the ZRC512 board plugged into an RC2014-compatible 3-slot
backplane together with Dylan Hall's CF-PPIDE module. I had no errors
copying back-and-forth between CF cards - this is with the bus running at
22MHz! And a neat light show watching the LEDs on the CF card interfaces
blinking rapidly in turn while copying from one card to the other ;-)

Here's an example power-up text (here with Dylan's CF-PPIDE module):

987650321
ZRC512 Monitor v0.3 10/15/23


>boot CP/M
4--ROMWBW: 4 press Return to execute command
S�

RomWBW HBIOS v3.4.0-dev.9, 2023-10-14

ZRC [RCZ80_zrc512] Z80 @ 21.996MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU
0KB ROM, 512KB RAM

CTC: IO=0x88 NOT PRESENT
ACIA0: IO=0x80 ACIA MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 Sat 2000-01-01 20:10:21 CHARGE=OFF
VRC: IO=0x00 NOT PRESENT
MD: UNITS=1 RAMDISK=256KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: ATA 8-BIT LBA BLOCKS=0x0007A800 SIZE=245MB
IDE1: NO MEDIA
PPIDE: IO=0x20
PPIDE0: ATA LBA BLOCKS=0x001E6C60 SIZE=973MB
PPIDE1: NO MEDIA
FP: IO=0x00 NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ACIA0:      RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      IDE0:       CompactFlash      245MB,LBA
Disk 2      IDE1:       Hard Disk         --
Disk 3      PPIDE0:     Hard Disk         973MB,LBA
Disk 4      PPIDE1:     Hard Disk         --


ZRC [RCZ80_zrc512] Boot Loader

Boot [H=Help]: c

Loading CP/M 2.2...

CBIOS v3.4.0-dev.9 [WBW]

Configuring Drives...

A:=MD0:0
B:=IDE0:0
C:=IDE0:1
D:=IDE0:2
E:=IDE0:3
F:=PPIDE0:0
G:=PPIDE0:1
H:=PPIDE0:2
I:=PPIDE0:3

1509 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

OK, now to the help I need. There is no RomWBW binary image build yet for
the ZRC512 board in Wayne's RomWBW distro, so I tried to assemble a more
recent image manually (Bill's image was of dev.9). I think it was in
dev.23 that Wayne fixed a bug where HW discovery failed to find the RTC
on reboot.

Bill has provided some brief information in the forum on how to make a
RomWBW image based on images for the ZRC and ZZRCC boards, but I've not
succeeded in building an image that will boot from the monitor into
RomWBW. Only by crudely manipulating binaries in a hex editor did I get
Bill's original ZRC512 Monitor (rev0.3) to work (somewhat) with RomWBW
dev.30.

What I need is a detailed howto and the necessary binaries for the loader,
the ZRC512 monitor and any other needed build files/scripts specifically
for the ZRC512. Any help would be appreciated.

Thanks, Paul

[Bill Shen]

Paul,
A compliment, an apology, and an addition to your post:

Compliment: That is a particularly very nice write up of ZRC512!  I'm linking to it on my ZRC512 homepage.

Apology: I've thought the latest RomWBW already has ZRC512 build files included, since they are on my local copy of dev_17 RomWBW.  Then I realized that was my own addition to dev_17.  Google forum and email have blocked .com and .cmd files from file uploads, so I didn't get these files to Wayne Warthen.  I just added them to ZRC512 homepage and here is the link.

Addition: you may be interested in this post in retrobrewcomputers.org where I've described the addition of keyboard/VGA to ZRC512 making it a standalone computer.  This is the direct consequence of making ZRC512 RomWBW compatible because Wayne Warthen has integrated the VGARC board into RomWBW so Z80/Z180/Z280 boards that runs RomWBW can become a standalone computer with the addition of the VGARC board.  VGARC in current implementation uses a 100-pin QFP EPM7128S.  I don't know whether you can work with 100-pin QFP, but the same design can be implemented in 84PLCC EPM7128S.  That 84PLCC design is on my next batch of pc board designs.
  Bill

[Wayne Warthen]

Thanks Bill.  You make this very easy for me!

I have posted RomWBW Development Snapshot v3.4.0-dev.31 with your changes to support ZRC512.  As usual, you can find this at the RomWBW GitHub Releases page.

Thanks,

Wayne

[Paul dB]

To just slightly modify Wayne's previous comment:

Thanks Bill and Wayne. You make this very easy for me!  8-D

And for the record, just to show how easy it is to "reflash" RomWBW on the ZRC512, here were my steps:

1. Download RomWBW-v3.4.0-dev.31-Package.zip
2. Extract 'hd1k_zrc512_combo.img' from the /Binary directory

3. Insert a CF card into a CF-to-USB adapter and plug it into your PC

4. Use rawwritewin.exe (from the /Tools/rawwritewin directory) to write the image to the CF card.

5. Plug the CF card into the ZRC512 board and apply power.

6. et voilà:

987650321
ZRC512 Monitor v0.3 10/15/23


>boot CP/M
4--ROMWBW: 4 press Return to execute command
S�

RomWBW HBIOS v3.4.0-dev.31, 2023-12-09

ZRC512 [RCZ80_zrc512] Z80 @ 21.996MHz

0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU
0KB ROM, 512KB RAM

CTC: IO=0x88 NOT PRESENT
ACIA0: IO=0x80 ACIA MODE=115200,8,N,1

DSRTC: MODE=STD IO=0xC0 Sun 2023-12-10 16:46:27 CHARGE=OFF

VRC: IO=0x00 NOT PRESENT
MD: UNITS=1 RAMDISK=256KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: ATA 8-BIT LBA BLOCKS=0x0007A800 SIZE=245MB
IDE1: NO MEDIA
PPIDE: IO=0x20
PPIDE0: ATA LBA BLOCKS=0x001E6C60 SIZE=973MB
PPIDE1: NO MEDIA
FP: IO=0x00 NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ACIA0:      RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      IDE0:       CompactFlash      245MB,LBA
Disk 2      IDE1:       Hard Disk         --
Disk 3      PPIDE0:     Hard Disk         973MB,LBA
Disk 4      PPIDE1:     Hard Disk         --

ZRC512 [RCZ80_zrc512] Boot Loader

Boot [H=Help]: c

Loading CP/M 2.2...

CBIOS v3.4.0-dev.31 [WBW]

Configuring Drives...

A:=MD0:0
B:=IDE0:0
C:=IDE0:1
D:=IDE0:2
E:=IDE0:3
F:=PPIDE0:0
G:=PPIDE0:1
H:=PPIDE0:2
I:=PPIDE0:3

1509 Disk Buffer Bytes Free

CP/M-80 v2.2, 54.0K TPA

Guys, many thanks for the help! Truly a creative group.

Thanks again,

Paul

[Wayne Warthen]

Glad to see it working Paul.  Since I don't have the hardware, it is always a question until someone actually does it.

Thanks for the kind words -- I do try to make it easy to update RomWBW.

-Wayne

[Bill Shen]

Thank you Wayne for updating the ZRC512 build files in your latest RomWBW.  I am juggling so many projects lately that I forgot to tell you about the ZRC512 build.  With the updates for ZRC512 and Z1RCC, I believe all three new ROM-less RomWBW-capable boards are covered.
  Bill

[Wayne Warthen]

No problem.  Always happy to support your work Bill!

-Waynbe

[Paul dB]

Now that my ZRC512 runs smoothly thanks to Bill and Wayne, I'll add to this topic some adventures I've had with NeoPixel-type RGB LEDs on the ZRC512 board.

td;lr Double-check the pinout of the "WS2812-type" LEDs you buy before powering-up - they may not have the same polarity as the ZRC512 board pinout (which is correct for Worldsemi's original WS2812B). Also, the order of the red and green colors can vary, ie GRB vs RGB.



I spent quite some time studying adverts on AliExpress to find information on WS2812-type LEDs (compatible or otherwise). Like usual, the far-East marketplace is a mess with advert titles containing lots of unnecessary and/or incorrect terms that, hopefully, search engines will latch onto.

Anyway, with some persistence, patterns can be found. The most important of which is that the manufacturers of these LEDs can't seem to agree on either the length or connections of the device's 4 leads.

So far I've found these four patterns of LED lead lengths:

Type 1: medium, long, medium, short
Type 2: long, long, short, short
Type 3: next longest, long, next shortest, short
Type 4: short, long, next shortest, short

The two inside leads always seem to be for VDD and GND. The outside two are for DIN and DOUT. However, a warning is appropriate here: a package's center leads DON'T always have the same polarity! And there are no markings on these LEDs (apart from lead lengths and, on most of them, one flat edge). I'm surprised that I couldn't find any information or warnings on the net regarding this. My guess is that nearly all of these LEDs are packaged as SMD and manufactured and sold in lengths with connections clearly marked. I certainly didn't find more than a couple of people blogging about the through-hole versions of these devices. The only remarks I found were about the order of the colors red and green, which can differ, ie some devices are GRB, others RGB.


Examples of pinouts I found:           WS2812B       APA-106        YF923-F8         Pololu "WS2812", 8mm

   _______ <-flat
  /       |1======        DOUT      DOUT      DOUT       DOUT
 / Type 1 |2========      VDD       GND       GND        GND  <- note these
 \  LED   |3======        GND       VDD       VDD        VDD  <- two rows!
  \_______|4====          DIN       DIN       DIN        DIN

                      Sparkfun "WS2812",5mm   YF923-F5   Pololu "WS2812",5mm
   _______ <-flat
  /       |1========      DOUT                DOUT       DOUT
 / Type 2 |2========      GND                 GND        GND
 \  LED   |3======        VDD                 VDD        VDD
  \_______|4======        DIN                 DIN        DIN

                          PL9823-F5/F8
   _______ <-flat
  /       |1========      DOUT
 / Type 3 |2==========    GND
 \  LED   |3======        VDD
  \_______|4====          DIN

                      Sparkfun "WS2812",Clear,5mm
   _______ <-flat
  /       |1====          DOUT
 / Type 4 |2========      GND
 \  LED   |3======        VDD
  \_______|4====          DIN


Note: no guarantees that I got all the above data correct!


Then there's the order of the red and green colors; some LEDs are GRB, others RGB, ie RED and GREEN reversed.

I bought batches of 50 "WS2812"-type LEDs from 2 different AliExpress sellers. One batch was claimed to be WS2812D LEDs with the 'Type 1' pinout above, and 'DOUT-VDD-GND-DIN', which seems to the "correct" order from Worldsemi, AFAIK the originator of these series-programmable RGB LEDs.

The other batch also claimed to be WS2812D LEDs, although further down in the advert the "specification" had "Part No: YF923-F5-F8". And even much further down I found the 5mm package had the 'Type 2' pinout above, with 'DOUT-GND-VDD-DIN'. Note the reversed polarity of the two batches, something I only understood later on. Interestingly, all of the look-alike LEDs I found, ie, not using a WS2812x chip, have the opposite polarity.

The ZRC512 board has the "Worldsemi WS2812x" LED pinout 'DOUT-VDD-GND-DIN' and I just happened to start testing with the YF923-F5 LED. Using DOUT as a reference, I plugged the LED just loosely into the holes on the board.

I powered up the ZRC512 after having assembled and uploaded Bill's WS2812 test program to a CP/M drive on the CF card. Ran the program and nothing happened. After a number of tries, I decided it was probably a good idea to learn a bit more about what I was doing.

That's when I discovered that these through-hole LED's 2 center leads can have the opposite polarity, ie VDD & GND reversed! Turns out I had killed off the first LED I tried, but before realizing that, and thinking the first one had been a dud, I managed to kill off yet a another one. Well that's why you buy a batch of 50 LEDs, right?

So, without any guarantees that the other batch of LEDs (the WS2812D) was wired any differently, I popped one in the board, powered-up again and re-ran the test program. Wow, it lives! And in glorious RED.

Modifying the test program, I also got GREEN, BLUE and WHITE to turn on.

Then the YF923-F5 LED (after 're-wiring' it) went through with flying colors (pun intended ;)) although RED and GREEN were reversed as expected (GRB for WS2812x, RGB for YF923-F5-F8).

In conclusion, the current bit-banged code works well with both LEDs. Nice work Bill!

Now I've only tried one LED so far. Bill's test program is written to control two LEDs, but I've studied the code and don't completely understand how the second line in 'ledTbl' works.

Here's the test program:

; test program for WS2812B pixel addressable LED
WS2812 equ 1eh ;bit bang WS2812

org 100h
jp start
ledTbl: db 0,8,0
db 10h,0,0
start:
di
ld hl,ledTbl
ld a,(hl)
ld b,8
doGrn:
out (WS2812),a ;11
rla ;4
djnz doGrn ;13 or 8 B==0

ld b,8 ;7
inc hl ;6
ld a,(hl) ;7
doRed:
out (WS2812),a
rla
djnz doRed

ld b,8
inc hl
ld a,(hl)
doBlue:
out (WS2812),a
rla
djnz doBlue

ld b,8
inc hl
ld a,(hl)
;second LED
doGrn2:
out (WS2812),a ;11
rla ;4
djnz doGrn2 ;13 or 8 B==0

ld b,8 ;7
inc hl ;6
ld a,(hl) ;7
doRed2:
out (WS2812),a
rla
djnz doRed2

ld b,8
inc hl
ld a,(hl)
doBlue2:
out (WS2812),a
rla
djnz doBlue2

ei
ld c,0 ;return to cp/m prompt
jp 5
end

I've (mostly) figured out what the first line in 'ledTbl' does:

  db 0,8,0   sets the 1st LED GRB colors to G="0" OFF, R="8" ON and B="0" OFF

But I don't follow how the second line works (apart from that it should somehow set the 2nd LED's colors):

  db 10h,0,0

I realize that the code needs to get the timing right, so I suspect some intricate algorithm is at work here.

Help, Bill, or anyone else wanting to chip in?

Thanks,

Paul

[Bill Shen]

Paul,
That's a great summary of various leaded NeoPixel available.  I have NO idea there are so many different flavors of leaded NeoPixel.  I've experimented with SMT version, but I'm very new to the leaded version.

I just received my package of World Semi WS2812D-F5 last night, so I plugged one in and saw it lit up...but it is the wrong color!  The order of colors for SMT WS2812B is green-red-blue, but for World Semi WS2812D-F5, the order of colors is red-green-blue.  So for WS2812D-F5, the test program has color values of zero_red, 8_green, 0_blue, and you should see a modest intensity green.  The color value is between 0 and $FF.  You can edit WS2812.COM with ZSID and change the ledTbl values starting from location $103.  For an example, if $103 is $FF and $104 and $105 are 0, you'll see an intense red.

The 2nd LED is for the 2nd NeoPixel whose Din is connected to 1st NeoPixel's Dout.  This is the purpose of the 3-pin header (T10-T11-T12) where T11 is Dout of the first NeoPixel to be connected to Din of the 2nd NeoPixel and daisy chained to hundreds, even thousands NeoPixels.

22MHz Z80 is not fast enough to bit-bang NeoPixel (actually not completely true, there are analog trick to make it work, but that's a different discussion), so there is a WS2812 circuit in CPLD to help generate the right duration pulses.  The test software is designed to work with the WS2812 circuit so it is incomprehensible by itself.  I've attempted a write up few weeks ago, but I don't think it is done.  Here is the link.  I have also described a bit-bang WS2812 with 36.8MHz Z180 here where I drove 5 WS2812B in series.
  Bill

[Bill Shen]

Paul,
This is the WS2812 circuit in CPLD.  The I/O address for WS2812 is 0x1E.  Data bit 7 decides whether the WS2812 output is pulse width of '1' (pulse width modulation, 67% high, 33% low) or pulse width of '0' (33% high, 67% low).  The expected sequence of instructions are:

loop:
  out (1eh),a
  rla
  djnz loop

1.27uS each loop which is the expected 800KHz pulse trains.  Do it 8 times per color value and 24 times per NeoPixel
  Bill

[Bill Shen]

[Paul dB]

Hi Bill,

Turns out, for some reason, I got stuck in my thinking when I had come to the fourth byte, 10h, in ledTbl while studying your test program. I think I had too many bits(!) going round in my head at the same time :/  I can understand if you were somewhat perplexed by my question!

Anyway, after taking a fresh look, the penny dropped. The test program uses fast "parallel-to-serial" code that, for each of three color bytes, rotates each bit left once per loop, spitting out bit7 each time to the logic in the CPLD. The bit value then pulse-code modulates the 800 Kbps bit stream that in turn controls the RGB LED(s). Wonder if I made that understandable?

To test my modification of the test program, I assembled a simple plugin board with 4 WS2812D LEDs. It's all good for now!

  Next I'll try some modifications of the test program; run in a loop, changing colors, etc. Sounds like fun :)

Thanks,

Paul

[Paul dB]

Bill, you wrote

"I just received my package of World Semi WS2812D-F5 last night, so I plugged one in and saw it lit up...but it is the wrong color!  The order of colors for SMT WS2812B is green-red-blue, but for World Semi WS2812D-F5, the order of colors is red-green-blue."

That's strange. The two Worldsemi datasheets I have of the LED variants both show GRB as being the color order. I'll attach them here.

Paul

[Bill Shen]

Paul,
Your explanation of the test software is exactly right.

I see you've daisy-chained the LED and drove them successfully.  You can buy 8x8 or even 16x16 WS2812B panels fairly cheaply and have fun with them.

The datasheets for WS2812D-F5 are perplexing because the color sequence is clearly red-green-blue for the batch of WS2812D-F5 that I purchased.  I tried another LED from the batch and it is the same.  So is your WS2812D-F5 have different color sequence?
  Bill

[Paul dB]

Bill,

Thanks for the confirmation.

The WS2812D-F5 LEDs I show in the last picture I posted actually do follow the datasheet, ie GRB. Are you sure your LEDs are genuine World Semi? The other batch I got was also supposed to be WD2812D-F5 although further down in the advert  they described the part as being YF923-F5. Those have the opposite, or RGB color order as well as having VDD & GND reversed! You're lucky that at least the polarity is correct 8)

Thanks,

Paul

[Bill Shen]

https://www.ebay.com/itm/234203893644
This is the eBay item I purchased.  The eBay advertisement does not say "World Semi", but the paperwork that was shipped with the package says they are "World Semi".   They do work and I am lucky the pin assignments all worked out.
  Bill

[Paul dB]

Hi Bill,

Sorry if I seem to be beating a dead horse here, but I got intrigued by the LEDs you bought, so of course I had to check a bit bit more.

I noticed the LEDs you received have the odd lead lengths, what I describe as 'Short-Long-NextLongest-NextShortest'. So I threw together a comparison, based only on World-Semi datasheets of WS2812D 5mm LEDs (the ones I could find). The one that matches the odd lead pattern is also the only one that is RGB!

Notice also that the company has changed the protocol timing in more recent part versions.

BTW, here are links to the two batches of WS2812D-F5 LEDs I got. The 3rd link is for a batch I haven't received yet. The info might be useful to someone.

CXY-BOM Store "WS2812D F5MM Lamp Beads"
https://www.aliexpress.com/item/1005005871456289.html

TELSDA Dream LED Store "WS2812D F5 5mm Frosted"
https://www.aliexpress.com/item/1005004993638820.html

JAD-LED Store "WS2812D F5 5mm Frosted"
https://www.aliexpress.com/item/4000879459147.html

Thanks,

Paul

[Bill Shen]

Thanks Paul, that's great detective work.  Changing color sequence may just be a function of how the LEDs are bonded out.  I'm interested in the timing of T0H, T1H, T0L and T0H; I see there are lots of variability.  It is pretty clear the products are evolving quickly.  Lead length pattern may be the best identification mark.  Attached is photo of my WS2812D-F5
  Bill

[Paul dB]

Bill, thanks for sharing a photo of your WS2812D-F5 LED. I couldn't help laughing when I saw it; that's par for the course. Not even this seller from Florida can provide correct info for the product he/she's selling.
(For those not following this rather long topic closely, the pattern of the leads don't match).

Should anyone want to dig further, not even Sparkfun can keep track of these WS2812-type LEDs. The "Customer Reviews" further down on that page sum it up quite well. And should you want to learn even more, clicking on the "Datasheet" link will bring you to a section that says:

"The datasheet for the WS2812 addressable through-hole LEDs is not clear with the pinout. For reference, you can refer to the bulb's flat edge and the length of the terminals as indicated below."

The labeled diagram shows a diffused LED with the VDD & GND leads switched when compared with the official WS2812 ones. So if you buy your WS2812 LEDs somewhere else and want to follow Sparkfuns' otherwise useful tutorial; caveat emptor.

Realistically  speaking, the market for through-hole WS2812 LEDs must be nearly non-existent, perhaps with the exception of a small, unimportant group of hobbyists like ourselves. For mass production, WS2812-based products, in surface-mount packaging, would be much, much cheaper to use. On World-Semi's WS2812 Family page, there are only 2 categories out of 12 for LED-type products; the rest are SMD.

Looking back, I think I could have summed all this up much earlier by saying that with the exception of a few "official" WS2812-type LED devices made by World-Semi, the rest are actually a product made by one company embedded within another company's product, ie a tiny speck of controller chip made by World-Semi or competitor, bonded (in some kind of order) to R, G & B LED dies (some even including a 4th, white LED die) in turn bonded (again, in some kind order) to 4 leads (of various lengths) encapsulated in epoxy (clear or frosted, long or short, narrow or wide, etc). Easy peasy 8)

Happy Holidays,
Paul

[Bill Shen]

I'll have to write about and refer to several discussions, including this one, in reference to W2812D-F5.  It is definitely a good practice to insert and test the part before soldering it.  It also make sense to fashion a tightly fit jumper from Din to Dout to bypass the on-board W2812D to drive the external W2812 panels.   The W2812 panels I'm familiar with have 3 leads and color coded, so there should be less confusion.

This remind me of the many different flavors of USB-serial adapters and different terminal emulation software on different platforms.  Some adapters are fakes and they have many different pin out.  It became (and still is) such a mess, I'd include an USB-serial adapter in my kit when I was selling hardware.
  Bill

[Paul dB]

Bill, good thinking about using a jumper from Din to Dout to be able to bypass the on-board WS2812D. But I'll assume that populating that part would then depend on whether or not an external panel is going to used, or can a WS2812D tolerate having Din connected to Dout?

Thanks,

Paul

[Bill Shen]

The on-board WS2812D can drive the external panel.  I was thinking of the scenario where on-board WS2812D is not populated then a jumper can be installed in the Din and Dout holes.   Maybe an "U shape" jumper fashioned out of cut-off LED lead will fit snugly in the holes without soldering.
  Bill

[Paul dB]

Yes, a cut-off LED lead worked perfectly. The lead is stiff enough to make a nice, tight fit. I added a short length of insulation from some wire "just in case".

   

Thanks,

Paul

[Paul dB]

I couldn't resist posting this image again, somewhat edited 8)

Paul

[Bill Shen]

LOL.  It is a winner of the “won’t take no for an answer” award.

  Bill

[Bill Shen]

Merry Christmas
  BIll

[Paul dB]

Nice, Bill. Is that a panel you got from eBay? 16x16 at full white must draw a bit of current. Realistically though, in 'normal' use it should just be a fraction of that.

Thanks,

Paul

[Bill Shen]

Yes, that is a panel from eBay for around $20.  I think it can draw 10amps when full on, but my power supply will current-limit first.  It is also very unhealthy for my eyes!
  Bill

[Paul dB]

On Wednesday 27 December 2023 at 17:17:30 UTC+1 Bill Shen wrote:

It is also very unhealthy for my eyes!

That I can believe! I made the mistake of lighting up just _1_ WS2812 LED to full white; could see that LED afterwards with my eyes closed ::- |

Paul

[Stefan V. Pantazi]

Hello!

Just built myself a ZRC512 + VGARC (with PS/2 kboard) combo so I can experience (first time for me) the RomWBW system on a stand-alone computer. Build went well, CF card was imaged with the zrc512_romwbw_hd1k_zrc512_combo and ZRC512 booted happily (in the serial console) and cleared the VGARC screen (hardware cursor visible). PS/2 keyboard was initialized as demonstrated by the blinking LEDs on it. While in RomWBW boot, I learned how to switch the screen from serial console to VGARC video with the i 1 command and video output works great. However, I am encountering some difficulties with making the PS/2 keyboard work. I did as much reading as I could but I am wondering whether there was something simple I am missing. Is there a command or a RomWBW boot setting I need to do to make the PS/2 keyboard input work? I am aware of CP/M 2.2 iobyte and stat commands to redirect IO but, I wonder if there is something else at the hbios level that would allow me to do the switch.

Thank you in advance!

Stefan

[Wayne Warthen]

Hi Stefan,

The keyboard should be activated along with the VGA display when you use the "I 1" command.  You shouldn't need to do anything else.  I will try this on my hardware tomorrow to confirm it is working for me.

Thanks,

Wayne

[Bill Shen]

You need these three lines to turn on VGARC
CRTACT .SET TRUE ; ACTIVATE CRT VDU,CVDU,PROPIO,ETC) AT STARTUP
VRCENABLE .SET TRUE ; VRC: ENABLE VGARC VIDEO/KBD DRIVER (VRC.ASM)
VDAEMU_SERKBD .SET $FF ; VDA EMULATION: SERIAL KBD UNIT #, OR $FF FOR HW KBD

See this link:
https://www.retrobrewcomputers.org/forum/index.php?t=msg&th=773&goto=10526&#msg_10526
  Bill

[Stefan V. Pantazi]

Thank you Wayne and Bill for the quick help!

I should have searched on  the retrobrew computers forum as well.

So far, for me it looks like the VGARC is enabled as both video and kbd devices appear in the list at boot.  The i 1 command does indeed activate the VGA output for me but the input remains on serial and PS/2 keyboard does not appear to do anything.

There may be some problem with keyboard for me only, although I do notice that at power on, the PS/2 keyboard lights blink.

I will keep investigating and will try to enter those commands at the startup to see if there is any difference.

Stefan

[Bill Shen]

Stefan,
The ZRC512+VGARC combination that I tested was some months ago with older RomWBW.  It did  not require command to enable video output.  In fact, once RomWBW has booted, it defaulted to video and PS2 keyboard and disabled the serial port.  This is the boot screen on my setup this morning (this is displayed on the TeraTerm console):

ø987650321

ZRC512 Monitor v0.3 10/15/23


>boot CP/M
4--ROMWBW: 4 press Return to execute command
S

RomWBW HBIOS v3.4.0-dev.17, 2023-12-03

ZRC [RCZ80_zrc512] Z80 @ 21.996MHz
0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU
0KB ROM, 512KB RAM

CTC: IO=0x88 NOT PRESENT
ACIA0: IO=0x80 ACIA MODE=115200,8,N,1

DSRTC: MODE=STD IO=0xC0 Sat 2000-01-01 00:00:02 CHARGE=OFF
VRC: IO=0x00 64X48 TEXT
KBD: IO=0xF4 MODE=VRC

MD: UNITS=1 RAMDISK=256KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC

IDE0: ATA 8-BIT LBA BLOCKS=0x0001E900 SIZE=61MB
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
FP: IO=0x00 NOT PRESENT

  Console on Unit #1

After that, all input/output are directed to PS2/VGA.  PS2 keyboard is strictly input device as implemented on VGARC, so you should not see commands going out to PS2 keyboard.  I attached a CF image of working ZRC512+VGARC.  Please give that a try.
  Bill

Google won't let me upload, so the image is stored in ZRC512 homepage here:
https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=builderpages:plasmo:zrc512:cf_image_romwbw_zrc512_working_vgarc.zip

[Stefan V. Pantazi]

Hi Bill,

That CF image worked perfectly. It indeed defaulted immediately to the video and PS2 keyboard. All seems perfect!

Just one more clarification regarding the VGARC hardware. I noticed the missing protection diodes for the VGA connection and I was wondering if I should bother adding them back. I tried once to add 1N4001 as in the schematic but only after I realized they should have probably been the Shottky fast type not 1N4001! These are slow and smear the pixels making the characters look funny. I took them out! What do you think?

Thank you again for the help!

Stefan

[Bill Shen]

Glad to hear your hardware is working properly with the older RomWBW image.  

I added diode protection as insurance, but have never populated them.  I think the 330 ohm series resistors with monitor’s internal 75 ohm terminations should be sufficient.  In my redesign of Z80ALL with PLCC84, the diodes were removed.

  Bill

[Wayne Warthen]

Hi Stefan,

Glad it is working.

It sounds like the first CF Card image you used had a problem with the "VDAEMU_SERKBD" configuration setting.  It should be $FF in the case of ZRC512, but seems as though it was set as $00.  I am trying to track down how you got such a build.  Couple questions:

• What version of RomWBW was it?
• Was this the prebuilt "RCZ80_zrc512.rom" image from the RomWBW distribution?  Or did you build your own ROM?

You may have already overwritten the problematic CF Card, so you may not have these answers, but anything you could tell me would be helpful.

I have confirmed that the RCZ80_zrc512.rom image in the latest stable release of RomWBW (v3.4.0) at the RomWBW GitHub Releases Page is properly configured.  It would be best if you updated your ROM to this image.  It should work correctly.  However, you should be prepared to revert to the working ROM image if necessary.

One last note.  The pre-built ROM image in the RomWBW distribution is not configured to default to the VGA console.  You would still need to use the Boot Loader command "I 1" to switch to the VGA monitor.  I distribute the ROM this way to ensure new users don't get tripped up by the output defaulting to the VGA connection.  It is trivial to make the VGA monitor be the startup console by building a new ROM with CRTACT set to TRUE.

Thanks,

Wayne

[Stefan V. Pantazi]

Hi Wayne,

I am happy to be learning more about the RomWBW. I think the following will answer both of your questions. The CF image I used initially was the only image listed on the zrc512 home page: https://retrobrewcomputers.org/doku.php?id=builderpages:plasmo:zrc512:zrc512home (more precisely, this one: https://retrobrewcomputers.org/lib/exe/fetch.php?media=builderpages:plasmo:zrc512:zrc512_romwbw_hd1k_zrc512_combo.zip ). RomWBW HBIOS version appeared to be 3.4.0-dev.9, dated 2023-10-14. I took a picture of the boot messages as they appeared on the serial port so this info is exactly what I had. This version is great for booting into the serial console.

However, I think Bill might have just uploaded the most recent version (the one that boots and goes right into the VGARC console) on that same page.

Regarding the pre-build ROM image. I agree it should be left as generic as possible. It was not difficult to figure the i 1 command from the wonderful documentation in the RomWBW github repository but I was confused as to why the PS2 keyboard would not work after issuing that command. Then I thought there had to be more to do than just one command expecting some sort of mechanism similar to the iobyte redirection from CP/M 2.2. From the discussion I see now that there are quite a few parameters that need to be set correctly in order for the all devices to be activated and for redirection to be done properly.

Thank you again for the work on RomWBW and for your help!

Stefan

[Stefan V. Pantazi]

Hi Wayne, 

I got to do a bit more playing around with booting in ZRC512 and realized I have more feedback to pass along. Of course, serial is still part of the picture. ZRC512 boots into the monitor first, which of course, is serial console only. That I can if necessary but I like the monitor too much for experimentation. Another thing I observed, more related to VGARC discussion is that, while in the RomWBW boot selection, if I choose to restart the machine with the R option, I lose both consoles, serial and VGARC. Only a hard reset gets me out by going back to the ZRC512 monitor and serial console and from there to RomWBW boot. It is not a big issue but I thought I may bring it up. I did not expect a soft reset/restart to persist the choice of the VGARC console but I think it should at least fall back to the serial console so there is no need for a hard button reset.

Stefan

[Bill Shen]

Wayne,
Hold off troubleshooting Stefan's issue with "R option".  The version of RomWBW I provided to Stefan is several months old.  Initially I want to make sure Stefan's PS2 hardware is working and that old RomWBW has served that purpose.  What I'll do now is pull the latest version of RomWBW, build it to work with ZRC512+VGARC and do some tests and pass it to Stefan for more tests.  If we've found problems, that'll be problems with current version of RomWBW instead of the months-old RomWBW.  Thanks,
  Bill

[Bill Shen]

Wayne,
On my ZRC512+VGARC setup, I can confirm what Stefan saw with older RomWBW that ZRC512 with VGARC will boot into VGA display and PS2 keyboard with serial port disabled.  Once in VGA/PS2 mode, the 'R' command will reboot, but then locked up.  I can also confirm the latest RomWBW will also lock up just like the older version

TL;DR

I pulled the latest RomWBW from dev branch and do the following:
edit the RCZ80_zrc512.asm in Source\HBIOS\Config to set true CRTACT

CRTACT            .SET TRUE                  ; ACTIVATE CRT VDU,CVDU,PROPIO,ETC) AT STARTUP

Then I execute several build commands under Source:

buildshared
buildimages
buildrom  (in the submenu specify RCZ80 then ZRC512)
buildzrc512

This will produce an image in Binary directory hd1k_zrc512_combo.img

I copy the image to a CF disk and boot up ZRC512.

This is the bootup display:

987650321
ZRC512 Monitor v0.3 10/15/23


>boot CP/M
4--ROMWBW: 4 press Return to execute command
S

RomWBW HBIOS v3.4.0-rc.4, 2024-02-07

ZRC512 [RCZ80_zrc512] Z80 @ 21.996MHz

0 MEM W/S, 1 I/O W/S, INT MODE 1, ZRC MMU
0KB ROM, 512KB RAM

CTC: IO=0x88 NOT PRESENT
ACIA0: IO=0x80 ACIA MODE=115200,8,N,1
DSRTC: MODE=STD IO=0xC0 Sat 2000-01-01 00:00:02 CHARGE=OFF
VRC: IO=0x00 64X48 TEXT
KBD: IO=0xF4 MODE=VRC
MD: UNITS=1 RAMDISK=256KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: ATA 8-BIT LBA BLOCKS=0x0001E900 SIZE=61MB
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT

CH0: IO=0x3E NOT PRESENT
CH1: IO=0x3C NOT PRESENT
FP: IO=0x00 NOT PRESENT

  Console on Unit #1S

After the above message is displayed on TeraTerm terminal, RomWBW disabled further serial communication and switched to PS2 and VGA.  While in PS2/VGA mode, I can type 'R', and it will reboot and display the same boot message on the serial port, but PS2/VGA is now locked up.

This the same problem as the months-old RomWBW.

  Bill

[Wayne Warthen]

Thanks for clarifying this Bill.  This issue it separate from the keyboard issue (which I hope is fully resolved).  It sounds like there is a bug related to the ROMless boot mechanism.  When (R)estarting under a ROMless configuration, the pre-existing HBIOS image is reused and I suspect something is not properly reinitialized with respect to the VRC driver.  I assume that performing a hardware reset (pushing reset button) works without issue.  I will try to track down the problem with the software (R)estart.

Thanks,

Wayne

[Wayne Warthen]

I have just posted RomWBW Development Snapshot v3.5.0-dev.10 at the RomWBW GitHub Releases Page.  This release corrects the problem Bill documented with respect to ROMless operation (R)estart at the Boot Loader prompt.

Thanks,

Wayne

[Stefan V. Pantazi]

Hi Wayne,

I followed the exact same steps as Bill described to generate a bootable CF disk image for ZRC512 with the CRTACT set to TRUE. I confirm that the warm reset (R option at boot selection) restarts the machine and the VGARC console remains active. the i 0 and i 1 commands also work as expected and allow me to switch between serial and VGARC consoles without any issues.

Thank you all for work!

Stefan

 

[Wayne Warthen]

Excellent.  Thank you for trying it Stefan!

-Wayne