SC126 strangeness

[Matt Balmer]

I have an SC126 that up until recently, was working just fine, but I can't seem to understand what's going wrong. 

The RomWBW startup banner lists ACSI0: and ACSI1: as both 115,200 bps, but it only operates at 38,400 bps -- trying to use the serial terminal at 115,200 simply generates garbage. The SCM ROM operates at 115k as expected. 

When I start up CP/M, the MODE command also lists the UARTs as running at 115,200, despite the fact that the serial port is actually running at 38,400.

Is there a reason that the serial port would be behaving this way? The only reason I can think of is that one of the current-limiting resistors going to the LEDs for the output ports actually have some relationship to the UART somehow -- I replaced the LED for bit 2 and it was very dim compared to the others, so I swapped the resistor out for a lower value. 

Is there something else in the circuit that determines the serial port speed that I'm missing?

[Dylan Hall]

This has come up a couple of times recently. Take a look at this thread https://groups.google.com/g/retro-comp/c/kx5-PaD7LwI/m/AFMsT1qJBAAJ

In short, try replacing the battery for the real time clock.

Dylan

--
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/88f86001-4042-428b-a025-01d6856ea46dn%40googlegroups.com.

[Matt Balmer]

I've tried replacing the battery, and the behavior on the board hasn't changed. Something is *clearly* off with the RTC because when I run RTC.COM from CP/M and just hold down "T", the clock ticks roughly two seconds for every second of actual time. 

For purposes of diagnosis, here's the RomWBW output upon boot:

RomWBW HBIOS v3.1.1-pre.185, 2022-12-16

Small Computer [SCZ180_126] Z8S180-N @ 3.112MHz IO=0xC0
0 MEM W/S, 2 I/O W/S, INT MODE 2, Z180 MMU
512KB ROM, 512KB RAM
ROM VERIFY: 00 00 00 00 PASS

AY: MODE=RCZ180 IO=0x68 NOT PRESENT
ASCI0: IO=0xC0 ASCI W/BRG MODE=115200,8,N,1
ASCI1: IO=0xC1 ASCI W/BRG MODE=115200,8,N,1
DSRTC: MODE=STD IO=0x0C Sat 2000-01-01 92:43:38 CHARGE=OFF
TMS: MODE=RC_V9958 IO=0x98 NOT PRESENT
MD: UNITS=2 ROMDISK=384KB RAMDISK=256KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: NO MEDIA
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
SD: MODE=SC OPR=0x0C CNTR=0xCA TRDR=0xCB DEVICES=1
SD0: SDHC NAME=SD64G BLOCKS=0x073E0000 SIZE=59328MB

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ASCI0:      RS-232            115200,8,N,1
Char 1      ASCI1:      RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          256KB,LBA
Disk 1      MD1:        ROM Disk          384KB,LBA
Disk 2      IDE0:       Hard Disk         --
Disk 3      IDE1:       Hard Disk         --
Disk 4      SD0:        SD Card           59328MB,LBA


Small Computer [SCZ180_126] Boot Loader

Boot [H=Help]:

The reason it's looking for a TMS chip is because I had been trying to get Dino Boards' V9958 video card working in the system and couldn't -- it would detect the card only intermittently -- but in my regular RC2014, it would detect just fine and worked great. 

It does seem like something is wonky with the RTC, but I'm not sure if that's really the source of it. I probed the clock signal coming out of the 32kHz crystal and it showed as 26kHz, and the 18.432MHz crystal kept showing up as some equally-wonky number, 15-and-change MHz. 

Then, oddly enough, I tried turning the board over to measure the frequency from the pins on the underside -- and after a couple of touches, suddenly the main clock crystal came right back to 18.432MHz. 

I rebooted the machine and it came right up at 115k. 

Needless to say, I've ordered a few spare 18MHz crystals just in case this one is marginal.

However, for whatever reason, the Yellow-MSX VDP board only rarely gets recognized, and when it does, it outputs garbage over the composite line. If it's in my RC2014, it outputs a cursor like I'd expect. I'm still not sure why it's not detecting properly in the SC126.

[Steve Cousins]

What happens if you remove the real time clock chip?

Can anyone say if the " Yellow-MSX VDP board only" is known to work with an 18 MHz Z180 system, and specifically with SC126?

Steve

[Wayne Warthen]

On Saturday, January 7, 2023 at 4:19:33 PM UTC-8 Steve Cousins wrote:

What happens if you remove the real time clock chip?

There is definitely a problem with the RTC circuit -- that is indicated by the clearly erroneous CPU speed in the boot messages.  RomWBW uses the RTC as a time constant to measure the CPU speed at boot.  If the RTC is not running properly, the CPU speed will be derived incorrectly.  When a bogus CPU speed is measured, RomWBW is unable to compute a reasonable divisor for the baud rate and uses a default divisor.  For a system running at 18.432 MHz, this default divisor will result in a baud rate of 38,400.  If you remove the RTC chip entirely, RomWBW will assume the CPU speed in the RomWBW config file which is 18.432 MHz (the correct value).  It will then compute a good baud rate divisor resulting in 115,200 baud operation.

If removing the RTC chip does indeed correct the baud rate, then you can go back to diagnosing why the RTC is operating incorrectly.

-Wayne

[Wayne Warthen]

On Saturday, January 7, 2023 at 4:19:33 PM UTC-8 Steve Cousins wrote:

Can anyone say if the " Yellow-MSX VDP board only" is known to work with an 18 MHz Z180 system, and specifically with SC126?

I tried the Yellow-MSX VDP board in my SC126.  It definitely did not work with standard Z180 timings.  However, I did get it to work by setting both the Z180 I/O wait states and memory wait states to maximum values (CPU speed was still the normal 18.432 MHz).  There is an I/O delay mechanism in the tms.asm video driver.  Tweaking this might improve things.

-Wayne

[Alan Cox]

> I tried the Yellow-MSX VDP board in my SC126. It definitely did not work with standard Z180 timings. However, I did get it to work by setting both the Z180 I/O wait states and memory wait states to maximum values (CPU speed was still the normal 18.432 MHz). There is an I/O delay mechanism in the tms.asm video driver. Tweaking this might improve things.

VDP99x8 do work with Z180 fine but all the delays in the driver will
be wrong because there are a set of required delays between accesses
to the device (it only has some many 'slots' per scan line for CPU
access). The 9938/9958 can also be set up to halt the processor if it
drives it too fast, but that feature is lacking on the 9918A and for
RC2014 assumes an 80 pin slot or jumper wires to access the signal

You say "cpu speed was still 18.432" but if you had max memory wait
states your effective CPU speed was nearer 8MHz, which is probably why
it worked 8)

Alan

[Matt Balmer]

>  I tried the Yellow-MSX VDP board in my SC126.  It definitely did not work with standard Z180 timings.  However, I did get it to work by setting both the Z180 I/O wait states and memory wait states to maximum values (CPU speed was still the normal 18.432 MHz).  There is an I/O delay mechanism in the tms.asm video driver.  Tweaking this might improve things.

Okay, so that explains some of it. Now, I'm wondering if I were to swap out the 18MHz crystal for an 8MHz one and left the timings alone, if that would take care of the problem of the card not being picked up or functioning, but it also makes me wonder if that would introduce other issues in the system. Perhaps Steve could shed some light on that.

As for the RTC circuit, since the issue apparently went away with only some simple probing, my money is more on the crystal itself being damaged somehow. 

[Matt Balmer]

Well, after more probing around and a little bit of experimentation, the issue came back -- the CPU kept coming up as 3.112 MHz (with a couple of times coming up as 3.120 MHz). So I decided to try it by pulling the RTC chip, and then the system reliably kept coming up as the normal 18MHz speed. Aaaaand now there's some replacement RTC clock chips on the way, as a result.

[Wayne Warthen]

On Sunday, January 8, 2023 at 3:26:16 AM UTC-8 etched...@gmail.com wrote:

VDP99x8 do work with Z180 fine but all the delays in the driver will
be wrong because there are a set of required delays between accesses
to the device (it only has some many 'slots' per scan line for CPU
access). The 9938/9958 can also be set up to halt the processor if it
drives it too fast, but that feature is lacking on the 9918A and for
RC2014 assumes an 80 pin slot or jumper wires to access the signal

Thank you for pointing this out Alan.  After a bit of research I realized that RomWBW

was not enabling the WAIT output of the 9958.  After enabling this via the

appropriate register during initialization, I was able to successfully run

the Yellow-MSX VDP board on my SC126 (Z180) with normal CPU settings.

Specifically, 18.432 MHz CPU clock, 0 added memory wait states and

1 added I/O wait states.  Very nice.  As you already mentioned, this is not

possible on the 9918 video module because the 9918 does not have the

CPU wait signal.

I also found that the probe for the chip could be made much more reliable

by adding extra delay during the probes read/write of RAM.  I will be checking

this change in to RomWBW dev branch shortly.

Thanks,

Wayne

[Matt Balmer]

That's awesome. I do have another question about getting this working, primarily for Wayne -- I remembered reading somewhere that if you're using a video output mechanism in RomWBW, it has to have a keyboard input tied to it -- you can't switch one independently of the other. Is that still the case with the TMS driver? Is it possible to have the console output over the V9958 board but still take input via serial, or do I need to build a keyboard interface for it, too? If I remember right, the 8242 keyboard controller is standard, but isn't the 8255 the controller typically paired with the V9958?

Thank you,

Matt Balmer

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/ydvZYCRSJTs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/c5d9a90c-67a9-4f28-9476-3e879a8d8166n%40googlegroups.com.

[Wayne Warthen]

On Monday, January 9, 2023 at 4:53:54 AM UTC-8 mba...@gmail.com wrote:

That's awesome. I do have another question about getting this working, primarily for Wayne -- I remembered reading somewhere that if you're using a video output mechanism in RomWBW, it has to have a keyboard input tied to it -- you can't switch one independently of the other. Is that still the case with the TMS driver? Is it possible to have the console output over the V9958 board but still take input via serial, or do I need to build a keyboard interface for it, too? If I remember right, the 8242 keyboard controller is standard, but isn't the 8255 the controller typically paired with the V9958?

Without doing some code hacking, it is true that RomWBW expects video devices to be "paired" with keyboards.  Prior to the RC2014 world, all of the video cards that RomWBW worked with included both a video and a keyboard interface.  The smaller RC2014 form factor makes it difficult to include both the video and keyboard circuitry on a single board, so things have gotten kind of confused.

With that said, the pairing mechanism in RomWBW is relatively flexible, but it cannot be done at runtime -- it must be configured when the ROM is built.  RomWBW has support for either an 8255 or 8242 attached keyboard.  The natural keyboard pairing for the Yellow MSX VDP board is the Yellow MSX Keyboard (https://www.tindie.com/products/dinotron/msx-keyboard-designed-for-rc2014/).  This pairing is fully supported and simple to configure.  Unfortunately, it looks like Dean is out-of-stock on the keyboards.

Using a serially attached keyboard with a dedicated video module has always seemed odd to me.  However, if there is a demand for this, I can look into it.  I really have not kept up with keyboard options for the RC2014.  I'm happy to look at supporting whatever is available.

Thanks,

Wayne

[Alan Cox]

> Using a serially attached keyboard with a dedicated video module has always seemed odd to me. However, if there is a demand for this, I can look into it. I really have not kept up with keyboard options for the RC2014. I'm happy to look at supporting whatever is available.

ZXkey is a simple 8 x 8 matrix at port 0xFF (uppler bits select the
lines to scan, result back). So you read 7FFF BFFF DFFF EFFF etc and
look in your key mapping table. Depending on the keyboard you may also
need to debounce.

PS2 card has a VT82C42 or similar at the PC I/O port numbers. It's one
one interrupt so you need to follow the polling rules (basically if
you read status and it says mouse, the next read must be the data and
it will be the mouse byte). Definitely the civilized option.

Bitbang PS/2 card is pretty much identical to the one you support on
the N8 but different port number and bits and also has a 4bit sound
out (for beep) and joystick in on the other bits (fire being up and
down together as was traditionally done way back)

And the universal microkeyboard is an arduino turning it into serial anyway

I would imagine the Omegax MSX keyboard will also work with the yellow
MSX card as it's an MSX keyboard.

Alan

[Matt Balmer]

And the universal microkeyboard is an arduino turning it into serial anyway

I would imagine the Omegax MSX keyboard will also work with the yellow
MSX card as it's an MSX keyboard.

The UMK is one reason that it might make sense to separate keyboard and display. At the same time, the Omega MSX keyboard uses the 82C55 PPI as its interface, which I believe Wayne has already said is supported natively. 

Personally, I believe that with the modular nature of the RC2014, it makes sense to have keyboard and display as separate devices -- that way, devices can be designed and tested individually without the need to write special I/O routines -- but I also understand Wayne's predilection towards having them be a pair because how often did we see a terminal keyboard with no screen, or a computer that has a screen, but no keyboard?

PS2 card has a VT82C42 or similar at the PC I/O port numbers. It's one
one interrupt so you need to follow the polling rules (basically if
you read status and it says mouse, the next read must be the data and
it will be the mouse byte). Definitely the civilized option.

I feel like I've seen this somewhere on Tindie, but I can't remember for certain. I'll have to go looking. That said, I've already got some of the components for an 82C55 PPI interface, I may just see if I can get a board made. 

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/ydvZYCRSJTs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAK9X0%2BvWwsOPTQ670bS%2BC3T8omkhbxXkfY18yBHYCiRnDYJB9Q%40mail.gmail.com.

[Alan Cox]

>> PS2 card has a VT82C42 or similar at the PC I/O port numbers. It's one
>> one interrupt so you need to follow the polling rules (basically if
>> you read status and it says mouse, the next read must be the data and
>> it will be the mouse byte). Definitely the civilized option.
>
>
> I feel like I've seen this somewhere on Tindie, but I can't remember for certain. I'll have to go looking. That said, I've already got some of the components for an 82C55 PPI interface, I may just see if I can get a board made.

https://hackaday.io/project/184729-rc2014-smart-ps2-keyboardmouse

[Wayne Warthen]

Thanks Alan.  Very helpful.  I'm thinking I will separate the keyboard and video drivers first, then come back to supporting more keyboards.

-Wayne

[Wayne Warthen]

On Tuesday, January 10, 2023 at 10:06:52 AM UTC-8 mba...@gmail.com wrote:

The UMK is one reason that it might make sense to separate keyboard and display. At the same time, the Omega MSX keyboard uses the 82C55 PPI as its interface, which I believe Wayne has already said is supported natively. 

Personally, I believe that with the modular nature of the RC2014, it makes sense to have keyboard and display as separate devices -- that way, devices can be designed and tested individually without the need to write special I/O routines -- but I also understand Wayne's predilection towards having them be a pair because how often did we see a terminal keyboard with no screen, or a computer that has a screen, but no keyboard?

Yup, I am going to pursue separating the keyboard and video drivers.  This is non-trivial for a few reasons (possibly more):

1. All keyboards and video are routed through terminal emulation code (usually ANSI) to provide a meaningful result.  This means it is not as simple as just pointing to a different device.
2. A keyboard driver is more than just a stream of input characters.  It understands shift-states, special keys, etc.  Likewise, a video driver handles cursor positioning, scrolling, etc.
3. RomWBW dynamically detects devices as it boots.  This means that device unit numbers are not static, so I need to find a reasonable way to specify how to pair arbitrary keyboard (or serial) devices and video devices without causing chaos when device unit numbers change.

I will need to think through this.

PS2 card has a VT82C42 or similar at the PC I/O port numbers. It's one
one interrupt so you need to follow the polling rules (basically if
you read status and it says mouse, the next read must be the data and
it will be the mouse byte). Definitely the civilized option.

I feel like I've seen this somewhere on Tindie, but I can't remember for certain. I'll have to go looking. That said, I've already got some of the components for an 82C55 PPI interface, I may just see if I can get a board made. 

Adding support for either an 8255 or 8242 based keyboard interface is pretty trivial.  The existing code should do all the heavy lifting.

Thanks,

Wayne 

[Bill Shen]

Wayne,
I'm also struggling with video/keyboard integration based on a specific set of CPLD-based video and PS2 hardware.  As I develop the BIOS for my particular video and keyboard, I still want to have console serial connection with my PC to transfer files, execute script files, and monitor Z80 computer activity.  So currently the CP/M BIOS polls input from both the console serial port and PS2 keyboard and send output to both video and console.  As you can imaging, the BIOS becomes bigger because now it needs to handle video font, video display memory, understand a subset of keyboard escape sequence, and PS2 lookup table for scan code, shifted scan code, and other key states.  I found it helpful to retain the ability of getting input from either PC or keyboard and send output to both PC and video.  Perhaps I may eventually cut the cord between PC and standalone Z80 computer but I feel that's long way down the road.

This is my feedback based on experience from a specific hardware platform, I'm looking forward to see a generalized solution to integrate various video and keyboard hardware into CP/M under RomWBW.
Bill

[Wayne Warthen]

Phillip reminded me that I should really try to get a new stable release of RomWBW done before I make architectural changes to separate the keyboard and video devices.  So, I went looking for a very simple way to provide an interim solution for this and I'm pleased to say that I believe I have done so.  This required only about 8 new lines of code and a one new configuration setting.

Basically, I have added a config setting called "VDAEMU_SERKBD".  This setting specifies a RomWBW Serial Unit # to be used for keyboard input to the ANSI terminal emulator (which coordinates all I/O to video display devices).  If the value is $FF, then it just reverts to a hardware keyboard as before.  If if is any other value, then keyboard input will come from the Serial Unit # corresponding to the value.  In most cases, you would use the value 0 to indicate you want keyboard input from the first serial device (the boot console).

By the way, the assumption here is that the serial input will already be ANSI encoded as desired.  In other words, pressing an arrow key on your PC emulators keyboard will send the ANSI escape sequence for the arrow key.  I think this makes sense.

This solution worked out much better than I expected, but I would like to hear feedback.

Thanks,

Wayne

[Alan Cox]

> This solution worked out much better than I expected, but I would like to hear feedback.

Works for me. That'll line up perfectly with Fuzix. I check for
supported keyboards and video. If I find both then I switch the
console to it. If I only find video then the video gets a copy of the
bytes sent to the serial (so ascii keyboards also work and throw away
the return). The PS/2 keyboard and serial output case isn't considered
- couldn't imagine a use case for it 8)

So I think it'll all work out fine for ROMWBW as well
- serial keyboard + video works
- true serial + video out works
- ps/2 or similar plus video out works

Alan

[Bill Shen]

Wayne,
I want to be a part of the RomWBW that integrates various video and keyboard hardware.  Instead of a serial video/keyboard terminal that converts keyboard input to serial input and serial output to video/graphic display like RC2014's Pi Zero terminal or Pi Pico VGA terminal, I have monochrome text-based video hardware that plugs in RC2014 bus.  On the keyboard input side, there is two I/O addresses for PS2 status and data such that status register indicates PS2 data is ready and data register contains buffered PS2 scan codes.  For the video output side, there are 1K of font memory representing 128 characters and 3K of text memory for 64 columns X 48 rows monochrome VGA text.  You can ignore the font memory since they are initialized at power up before RomWBW is called.  The 3K text are read/write addressable taking up 3K of I/O space.  Video text can be read and write any time, no need to synchronize to VGA's vertical or horizontal sync.

Since video memory existed in I/O space, it does not taken up valuable BIOS memory space, but PS2 input processing is a significant memory hog.  The scan code and shifted scan code tables take up 256 bytes of space and the rather complex keyboard data processing also takes up program memory.  The basic hardware (VGARC) was designed in late 2019, but I've intermittently working on integrating it into CP/M for the last 3 years!  

This is a rather long description of a particular video/keyboard hardware, but what I'm hoping for is for it to be integrated into RomWBW framework.  I think PS2 keyboard integration is problematic; perhaps I should use 8042/8242 keyboard controller or perhaps banked RAM for BIOS is the answer.  I have 3,4 maybe 5 hardware platforms at various stages of development with various flavors of the video/keyboard, some of them may be too spartan to be a part of RomWBW (such as Z80all), but I hope one or more of them can evolve to be compatible with RomWBW.

I like to see a new topic about standalone Z80 with RomWBW handling different flavors of video and keyboard components.
 Bill

[Wayne Warthen]

This is good to hear Alan.  Thanks!

-Wayne

[Wayne Warthen]

Sounds good to me Bill.  I'd be happy to support this.

I don't see a problem supporting your custom PS/2 interface.  The bulk of the existing PS/2 keyboard code relates to the handling of the raw scan codes and that would not change.  Yes, the PS/2 scan code processing requires a good hunk of code and tables, but that all resides in a separate bank under RomWBW.  Banked RAM/ROM is pretty much a requirement of RomWBW, so hopefully that is not an issue here.

The video memory in I/O space may be tricky.  RomWBW is not generally coded to mange the top half of the I/O addressing.  Thus far, all platforms supported by RomWBW only decode the low 8 bits, so it has never been relevant (Z180 register I/O is a special case).

Yes, this deserves it's own topic.  As you are ready, start a new topic and we can work through this.

Thanks,

Wayne 

[G Kr]

Speaking of Fuzix for SC126: Currently there is no directory for the SC126 platform in the kernel directory at https://github.com/EtchedPixels/FUZIX. Is there anything to expect in the foreseeable future?

Gerd

[Ed Brindley]

SC126 is supported by the rcbus-z180 target https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/platform-rcbus-z180/README

[G Kr]

Ah, thank you very much. Searching the sources would have helped... didn't think of it.

Gerd