RomWBW digital I/O input at startup

[Dylan Hall]

This is a random thought mostly for Wayne :)

I was thinking about the Altair-Duino and how it uses the front panel switches to control the boot process. Given that RomWBW will already use a digital I/O module for displaying POST style boot progress I was wondering how hard would it be to influence the boot process by reading the same digital I/O module. 

For example, if the value is non-zero, select CP/M 2.2, or the Monitor, or which device/slice to boot etc.

Would this be useful, and if so, would it be hard to implement?

Dylan

 

[Pellatonian]

I put a few changes in RomWBW some time ago to do something similar.

Switch 1 enables autoboot from whichever drive is selected (see below) or entry to the RomWBW monitor.

Switch 2 selects which of SerialA or SerialB is the console.

Switches 3-5 select the boot device 0-7.

Switches 6-8 select the unit on the device 0-7.

Note: Autoboot boots the device immediately, not after a configured timeout.

Clearly some changes would have to be made for drives greater than H:

I did this maybe 3 or 4 years ago so the level of RomWBW is quite obsolete but if I remember correctly they were quite easy, especially if you already knew the code.

Example for SC126:

[Alan Cox]

NVRAM could also be used for this. The problem with the digital I/O
module having done this on some non Z80 stuff is that the digital I/O
module is itself not probeable so you can't tell if you have a set of
front panel switches to know if you should read the front panel
switches.

This is fine if you are building something custom but to make ROMWBW
more generic really IMHO you'd want to go NVRAM because you could then
store actual type/address pairs and build ROMWBW for a bunch of stuff.
That way you'd be able to boot it in 'serial no disk I/O n video' and
set NV parameters for your video / sd / cf / etc.

[Steve Cousins]

Regarding Alan's comment about probing for digital I/O modules:

The latest version of SCM provides a configuration option to specify the way SCM determines if it should consider a digitial I/O module to be present or not. See code below.

However, it uses a dirty trick that works with standard RC2014 configurations but might not work on customised versions. Specifically, if the data bus has any loading other than CMOS ICs. The code relies on the data bus not being terminated. The data lines then hold their last active signals for a short while enabling them to be read back. If no device is present the value read from the address will be the same as the last byte of the instruction. If a device is present at the address the values read back will be the same regardless of the instruction used to read that address.

Steve

#IF         DiagLEDs_DETECTED = "TESTABLE"
; Test if reading from port appears to be an unused address (floating)
; This only works if the data bus is not terminated and the diagnostic
; LED port address also includes an input port
            LD   C,kDiagBase    ;Digital I/O port address
            IN   C,(C)          ;Read from this port
            IN   A,(kDiagBase)  ;Read again using different instruction
            CP   C              ;Both the same? (bus not floating)
            RET                 ;Return Z flagged if found
#ENDIF
#IF         DiagLEDs_DETECTED = "ALWAYS"
            XOR  A              ;Always return device detected
            RET                 ;Return Z flagged if found
#ENDIF
#IF         DiagLEDs_DETECTED = "NEVER"
            OR   0xFF           ;Never return device detected
            RET                 ;Return Z flagged if found
#ENDIF

[Wayne Warthen]

Very easy to implement and I think it is a good idea.

The only thing I am wondering about is if I can detect the presence of the digital I/O module.  If it is not present, the port will not read 0x00.  I need to make sure a bogus value is not read when no Digital I/O is present.  It could be made a custom build option, but would be nicer if I can just detect it and use it if it is there.

I really need to focus on getting a new stable release issued, but will work on this right after that.  In fact, I am going to add this as an issue (enhancement request) on the RomWBW GitHub site so I don't lose track of it.  See RomWBW Issue #315.

Thanks,

Wayne

[Wayne Warthen]

On Thursday, January 19, 2023 at 4:15:01 AM UTC-8 etched...@gmail.com wrote:

NVRAM could also be used for this. The problem with the digital I/O
module having done this on some non Z80 stuff is that the digital I/O
module is itself not probeable so you can't tell if you have a set of
front panel switches to know if you should read the front panel
switches.

This is fine if you are building something custom but to make ROMWBW
more generic really IMHO you'd want to go NVRAM because you could then
store actual type/address pairs and build ROMWBW for a bunch of stuff.
That way you'd be able to boot it in 'serial no disk I/O n video' and
set NV parameters for your video / sd / cf / etc.

NVRAM configuration is definitely on the list for RomWBW.  I don't have a problem supporting both things though.  The switches are a nice way to modify the boot behavior for an individual boot, whereas the NVRAM is ideal for setting overall system defaults and configuration.

Yes, detection of the Digital I/O is critical.

Thanks,

Wayne

 

[Wayne Warthen]

On Thursday, January 19, 2023 at 9:23:05 AM UTC-8 Steve Cousins wrote:

Regarding Alan's comment about probing for digital I/O modules:

The latest version of SCM provides a configuration option to specify the way SCM determines if it should consider a digitial I/O module to be present or not. See code below.

However, it uses a dirty trick that works with standard RC2014 configurations but might not work on customised versions. Specifically, if the data bus has any loading other than CMOS ICs. The code relies on the data bus not being terminated. The data lines then hold their last active signals for a short while enabling them to be read back. If no device is present the value read from the address will be the same as the last byte of the instruction. If a device is present at the address the values read back will be the same regardless of the instruction used to read that address.

Steve

#IF         DiagLEDs_DETECTED = "TESTABLE"
; Test if reading from port appears to be an unused address (floating)
; This only works if the data bus is not terminated and the diagnostic
; LED port address also includes an input port
            LD   C,kDiagBase    ;Digital I/O port address
            IN   C,(C)          ;Read from this port
            IN   A,(kDiagBase)  ;Read again using different instruction
            CP   C              ;Both the same? (bus not floating)
            RET                 ;Return Z flagged if found
#ENDIF
#IF         DiagLEDs_DETECTED = "ALWAYS"
            XOR  A              ;Always return device detected
            RET                 ;Return Z flagged if found
#ENDIF
#IF         DiagLEDs_DETECTED = "NEVER"
            OR   0xFF           ;Never return device detected
            RET                 ;Return Z flagged if found
#ENDIF

This is pretty good Steve.  I do something similar to detect hardware in some drivers, but your approach is more thorough.  I would probably consider 0xFF to also mean nothing is there.  That would handle a terminated bus.  It just means the user could not use the value 0xFF which is probably not a problem in this use case.

Thanks,

Wayne 

[Wayne Warthen]

On Thursday, January 19, 2023 at 3:00:58 AM UTC-8 Pellatonian wrote:

I put a few changes in RomWBW some time ago to do something similar.

Switch 1 enables autoboot from whichever drive is selected (see below) or entry to the RomWBW monitor.

Switch 2 selects which of SerialA or SerialB is the console.

Switches 3-5 select the boot device 0-7.

Switches 6-8 select the unit on the device 0-7.

I like these switch definitions as a starting point.  If others have ideas, I would be interested to hear them.

I think that the official digital I/O card uses momentary tactile switches, right?  Those won't be ideal to select boot options because it is hard to hold multiple of them down or leave them set a certain way.  I don't have a solution for that.

Thanks,

Wayne

 

[Dylan Hall]

Pellatonian - That is a beautiful build :)

Wayne - Thanks for creating the github issue to track this. In terms of the hardware I had been thinking of Steve's SC129 with toggle switches attached. I hadn't realised the official module uses momentary switches.

Thanks,

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/89dd52e9-5571-4aa6-bbd7-a1e67e5da6c2n%40googlegroups.com.

[Alan Cox]

> However, it uses a dirty trick that works with standard RC2014 configurations but might not work on customised versions. Specifically, if the data bus has any loading other than CMOS ICs. The code relies on the data bus not being terminated. The data lines then hold their last active signals for a short while enabling them to be read back. If no device is present the value read from the address will be the same as the last byte of the instruction. If a device is present at the address the values read back will be the same regardless of the instruction used to read that address.

Not entirely sure it'll work on a loaded bus either. It's getting late
but I will try and test this logic on my fully populated backplane
tomorrow. if it works there it ought to work anywhere 8)

[Alan Cox]

On Fri, 20 Jan 2023 at 00:14, Dylan Hall <dy...@deedums.com> wrote:
>
> Pellatonian - That is a beautiful build :)
> Wayne - Thanks for creating the github issue to track this. In terms of the hardware I had been thinking of Steve's SC129 with toggle switches attached. I hadn't realised the official module uses momentary switches.

There is a module that uses switches. Z80 PIO cards also work. I
guess it's mostly a case of agreeing what I/O port to use as a console
switch set

https://oshwlab.com/peabody1929/RC2014_Digital_I_O_Board-b99bbed96f0543e5a388c3387281c611

The other switch option I'd want would be vdu/kbd or serial.

The switches probably also need to not make sense when floating at
things like 78 and other bus things as well.

Alan

[Wayne Warthen]

On Thu, Jan 19, 2023 at 4:14 PM Dylan Hall <dy...@deedums.com> wrote:

Wayne - Thanks for creating the github issue to track this. In terms of the hardware I had been thinking of Steve's SC129 with toggle switches attached. I hadn't realised the official module uses momentary switches.

Yeah, anything like the SC129 will make sense.  The momentary switches might be marginally useful.

-Wayne 

[Wayne Warthen]

On Thu, Jan 19, 2023 at 5:13 PM Alan Cox <etched...@gmail.com> wrote:

There is a module that uses switches.  Z80 PIO cards also work. I
guess it's mostly a case of agreeing what I/O port to use as a console
switch set

https://oshwlab.com/peabody1929/RC2014_Digital_I_O_Board-b99bbed96f0543e5a388c3387281c611

I had not seen this one.  Thanks.  Interesting to see this one is preconfigured for port 0xFF.  All of the other digital I/O boards are using 0x00 I think.  I'm inclined to think of 0x00 as the default.

-Wayne

The other switch option I'd want would be vdu/kbd or serial.

Really good point.  That would be extremely useful.

The switches probably also need to not make sense when floating at
things like 78 and other bus things as well.

I think Steve's code would catch the 0x78 value, right?

-Wayne

[Alan Cox]

> I had not seen this one. Thanks. Interesting to see this one is preconfigured for port 0xFF. All of the other digital I/O boards are using 0x00 I think. I'm inclined to think of 0x00 as the default.

The zxkey keyboard driver also uses FF and has to for ZX81 and any
future ZX Spectrum emulation games because that is where Sinclair
stuck the original. It's also the write port for the MMU on some of
the non Z80 ports so 0 sounds a good idea to me too.

For autodetect I realize there may be a really simple easy approach

Wire all the switches not to ground and vcc but to ground and output
pin 0. Now you can write port 0 so that bit is low, read back 0x00,
write the bit high and read back switches. Anything else and it's not
the port you were looking for.

Alan

[Wayne Warthen]

On Thursday, January 19, 2023 at 5:58:05 PM UTC-8 etched...@gmail.com wrote:

For autodetect I realize there may be a really simple easy approach

Wire all the switches not to ground and vcc but to ground and output
pin 0. Now you can write port 0 so that bit is low, read back 0x00,
write the bit high and read back switches. Anything else and it's not
the port you were looking for.

If all the switches were open, then you would not detect the board, right?  May not matter if all switches open is the default value.

-Wayne 

[Dylan Hall]

That's brilliant! :)

Dylan

On Tue, 7 Mar 2023 at 23:14, Wayne Warthen <wwar...@gmail.com> wrote:

While waiting for feedback on the RomWBW Release Candidate, I spent a few minutes thinking about this proposal about leveraging digital I/O switches to control RomWBW bootup.  Below is the concept I came up with based on input thus far.  I find it easier to visualize usage with something like this.  The graphic is intended to mock up a conceptual front panel based on the Digital I/O card -- similar to the example in the post below.  Thoughts?

In case it needs to be clarified, the meaning of the switches is:

Auto/Menu: Auto boot or console menu

CRT/Serial: Default to serial console or CRT console

Sec/Pri: Switch primary/secondary console port

Disk/ROM: Boot disk device or ROM applications

Floppy/Hard: If disk boot, boot to first floppy or first hard disk

ROM App/Boot Slice: ROM App (if ROM boot) per legend or disk slice (if disk boot)

Thanks,

Wayne

On Thursday, January 19, 2023 at 3:00:58 AM UTC-8 Pellatonian wrote:

--

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/a80ec647-f5b0-488f-a8f2-4ba043b2110an%40googlegroups.com.

[Spencer Owen]

That looks good Wayne,

I am trying to get my head around the use cases for this without any input panel, which I would assume should boot in to the regular menu offering Z,C,B,F etc to boot from via keyboard.  The Digital I/O module is by far the most common expansion for the RC2014 that I supply, so most people have probably already got a way to implement this.  However, this has tact-switches not toggle switches, but as this would only need to be read on bootup, holding down a button or two for a couple of seconds should work well.  A Digital I/O Module without any buttons pressed would be the same as no input panel I guess..

It would be nice if the most likely* alternative boot modes could be selected with just 1 button being held in on startup.  ie the 3 ROM boot options would be Z-System, CP/M, BASIC based on my most likely* use case, so a 1, 2 or 4 from the ROM buttons. 3, 5, 6 and 7 would need multiple buttons holding down, so those would be the less likely* options of Forth, Game, Net, User

* I appreciate that my "most likely" booting scenarios are different from others, and I doubt there will be a One-Size-Fits-All solution.

Spencer

On Tue, 7 Mar 2023 at 10:14, Wayne Warthen <wwar...@gmail.com> wrote:

While waiting for feedback on the RomWBW Release Candidate, I spent a few minutes thinking about this proposal about leveraging digital I/O switches to control RomWBW bootup.  Below is the concept I came up with based on input thus far.  I find it easier to visualize usage with something like this.  The graphic is intended to mock up a conceptual front panel based on the Digital I/O card -- similar to the example in the post below.  Thoughts?

In case it needs to be clarified, the meaning of the switches is:

Auto/Menu: Auto boot or console menu

CRT/Serial: Default to serial console or CRT console

Sec/Pri: Switch primary/secondary console port

Disk/ROM: Boot disk device or ROM applications

Floppy/Hard: If disk boot, boot to first floppy or first hard disk

ROM App/Boot Slice: ROM App (if ROM boot) per legend or disk slice (if disk boot)

Thanks,

Wayne

On Thursday, January 19, 2023 at 3:00:58 AM UTC-8 Pellatonian wrote:

--

[Wayne Warthen]

On Tue, Mar 7, 2023 at 3:52 AM Spencer Owen <spe...@sowen.com> wrote:

I am trying to get my head around the use cases for this without any input panel, which I would assume should boot in to the regular menu offering Z,C,B,F etc to boot from via keyboard.  The Digital I/O module is by far the most common expansion for the RC2014 that I supply, so most people have probably already got a way to implement this.  However, this has tact-switches not toggle switches, but as this would only need to be read on bootup, holding down a button or two for a couple of seconds should work well.  A Digital I/O Module without any buttons pressed would be the same as no input panel I guess..

Indeed, this is primarily intended for people to create front panels with toggle switches vs. tactile switches.  I played around with scenarios where everything was done with just a single button press, but sadly, I just could not come up with anything I considered reasonable.  It is designed such that a Digital I/O Module with no buttons pressed is effectively the same thing as having no input at all.

It occurred to me that a variant of the Digital I/O Board based on sub-mini slide switches might be interesting.  https://www.mouser.com/ProductDetail/CK/js102011cqn?qs=j%252B1pi9TdxUaTejr8RwGFYA%3D%3D

It would be nice if the most likely* alternative boot modes could be selected with just 1 button being held in on startup.  ie the 3 ROM boot options would be Z-System, CP/M, BASIC based on my most likely* use case, so a 1, 2 or 4 from the ROM buttons. 3, 5, 6 and 7 would need multiple buttons holding down, so those would be the less likely* options of Forth, Game, Net, User

* I appreciate that my "most likely" booting scenarios are different from others, and I doubt there will be a One-Size-Fits-All solution.

This is a good point.  There was no particular reason for the codes I assigned for ROM boot options.  As you say, everyone will have a different idea of the most likely boot selections, but your suggestions seem about right to me.  How about this:

ROM Apps:   0=Monitor   1=CP/M 2.2   2=Z-System   3=Forth   4=BASIC   5=Game   6=Net Boot   7=User

I think the implication is that if any of the ROM App switches/buttons are pushed/set, then an "auto" boot is implied.  Otherwise, 2 buttons would need to be pressed.  Possible, but harder.

Also, I intend to make these selections somewhat configurable, but would require a custom build.

Thanks,

Wayne

[Wayne Warthen]

On Fri, Mar 10, 2023 at 2:10 AM Bill Shen <coinst...@gmail.com> wrote:

I like the idea of booting based on switch configuration.  The "switch" can be discrete I/O board or RAM board (I'm thinking of video RAM board that's mapped to I/O 0x0) or even a weakly pullup/pulldown resistor block.

Right.  The only thing is that RomWBW  is going to probe for an input port at 0x0 (or a configurable port address).  As long as something looks like it is providing a value (not floating), RomWBW will consider the value to be switch settings and handle accordingly.  Note that this feature is just under discussion right now.  I will be implementing it in a release after the upcoming stable v3.2 release.

Does current RomWBW has a way to boot into a predefined configuration?

Currently, only if you build a custom ROM.  It is a deficiency that I am addressing with the whole switch setting things.

Thanks,

Wayne 

[Wayne Warthen]

I have checked in support for the use of switches to control RomWBW boot configuration.  The default configuration for all RC2014 systems will look for a port at 0x00 (standard digital I/O port) and , if found, use the switch values to control boot.  The conceptual front panel for this functionality is shown below.

See RomWBW GitHub Issue #315 for more discussion.  The functionality is available in the latest Development Snapshot on GitHub at the RomWBW Releases page.  To be clear, the functionality is not in the current stable release v3.2.1.  You must get the latest Development Snapshot if you want to try it.

I would be very interested in comments about this.

Thanks,

Wayne

[Wayne Warthen]

It occurred to me that it may be better to group the switches.  There are console selection switches and boot switches.  Any feedback on rearranging the switch assignments as shown below?

Thanks,

Wayne

[positron (Jose L. Collado)]

Hi Wayne, thanks for this cool retro feature ! The proposed layout looks great and is very intuitive.

Time to mod my SC-126 custom case…

Regards, JL.

[Dylan Hall]

Thanks Wayne, I'll try it out as soon as I can free up some hardware from another project :)

Regarding the layout, I'm in too minds. Grouping the console and boot switches together makes more sense, but on the other hand I imagine the switch I'd use most often would be the auto/menu switch so having that on the left feels more convenient. On balance however, I think grouping the switches is the better option.

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/acc3ea06-e6e6-4fec-997a-4c138c7357dfn%40googlegroups.com.

[Wayne Warthen]

On Monday, April 17, 2023 at 3:56:12 PM UTC-7 Dylan Hall wrote:

Regarding the layout, I'm in too minds. Grouping the console and boot switches together makes more sense, but on the other hand I imagine the switch I'd use most often would be the auto/menu switch so having that on the left feels more convenient. On balance however, I think grouping the switches is the better option.

Funny.  That's exactly the same thought process I went through. 

[Derek Cooper]

Hi, the low 4 switched on the right are called Rom App/ Boot slice. I assume the function depends on Disk/ROM switch? if so, why not consider moving it one to the right so it's next to the selection switches?

Derek

[Wayne Warthen]

On Tuesday, April 18, 2023 at 3:17:06 AM UTC-7 Derek Cooper wrote:

Hi, the low 4 switched on the right are called Rom App/ Boot slice. I assume the function depends on Disk/ROM switch? if so, why not consider moving it one to the right so it's next to the selection switches?

That is a good point Derek.  It is not obvious,  but when the user chooses Disk + Floppy the last 3 switches will allow booting from a selected floppy drive.  So, although it is not well labeled, both the Disk/ROM and Floppy/Hard switches effect the function of the last 3 switches.  I found it hard to come up with a way to label things that make the floppy selection obvious.  I guess I also feel like there is something "natural" about having the App/Slice/Floppy switches aligned with the low order bit positions.

With all of that said, I very much wish to hear other comments about this and I will be easily swayed by group opinion!  😀

Thanks,

Wayne

[Alan Cox]

A slightly more off the wall question - does it need to be all 8 bits ?

If one input bit is free then you can get an SD card, some status LEDs
and the switches off the one card using a variant of the PIO SD driver
code and without any hardware changes just a cheap Arduino Sd adapter
and some wire. With one spare bit you'd be able to set it up as 7
config switches and MISO, and on the output bits MOSI, SCK, SS (also
the disk LED) and 5 status bits and get your I/O, status and switches
on a single cheap and easy to build board.

Also for the switch arrangements does it not need to be the case that
38 or 78 is not a sensible configuration because of the floating bus
and lack of detect ?

Alan

[Wayne Warthen]

On Wednesday, April 19, 2023 at 2:16:09 AM UTC-7 Alan Cox wrote:

A slightly more off the wall question - does it need to be all 8 bits ?

From the perspective of the front panel, no.  However, I have frequently used

all 8 bits of the Digital I/O during code development/debugging so that

I can expose or inject a byte value at times when it is not reasonable to

use the console.

If one input bit is free then you can get an SD card, some status LEDs
and the switches off the one card using a variant of the PIO SD driver
code and without any hardware changes just a cheap Arduino Sd adapter
and some wire. With one spare bit you'd be able to set it up as 7
config switches and MISO, and on the output bits MOSI, SCK, SS (also
the disk LED) and 5 status bits and get your I/O, status and switches
on a single cheap and easy to build board.

I have frequently lamented the lack of a simple SD Card interface for much

of the RCBus world.  The only place I have seen it are in Stephen Cousins'

Z180 systems.  The MT011 provides an SD Card interface, but it a fairly

sophisticated board.  As you say, a basic SPI connection is trivial and

RomWBW has general support for this already.

With that said, I would be happy to support a hardware variation as you

suggest.  On my end, it's just simple software.  😀

The RTC module also has I/O with a latch.  My personal preference would

be an updated RTC board with 1 or 2 SPI ports.  Part of this is a bias to

have NVRAM on most systems because I absolutely believe that NVRAM

is the answer to many basic system configuration options (like serial

port baud rate).  I will absolutely be pursuing NVRAM usage in RomWBW

in the near(ish) future.

Also for the switch arrangements does it not need to be the case that
38 or 78 is not a sensible configuration because of the floating bus
and lack of detect ?

I am currently using the port detection algorithm that Stephen Cousins

suggested.  At least empirically, I am finding that I can read a port with

IN (n) and IN (C) and the values will be different if the port is floating.

Typically, I see IN (n) return 0x78, but IN (C) almost always returns the

value of the port being read.  I have not seen 0x38 yet.  I do also weed

out 0xFF.  These definitely would be a problem if the port address was

0x78.  If you think I am missing something, please let me know.

Thanks,

Wayne

[Steve Cousins]

Earlier in this discussion Wayne suggested a module similar to the digital I/O module but with slide switches to select boot options in RomWBW.

Would something like this be a useful addition to the options available for people to customise their systems?

[Wayne Warthen]

This is exactly what I had in mind.  Looks awesome to me, but I am very biased.  😀

-Wayne

[Alan Cox]

On Sat, 22 Apr 2023 at 20:47, Steve Cousins <steve...@gmail.com> wrote:

Earlier in this discussion Wayne suggested a module similar to the digital I/O module but with slide switches to select boot options in RomWBW.

Would something like this be a useful addition to the options available for people to customise their systems?

I would probably put them on the case (and I'd rather have them in the RTC with an override but that's a different story). For that style though the one thing I would consider adding would be a reset button ?

Alan

 

[Dylan Hall]

I was thinking along these lines (I really like toggle switches).

With a second PCB sandwiched over the top, e.g.

I'd fit spacers to the LED's so they sit roughly level with the switches.

A variation on the theme would be to connect the back PCB to an SC129 Digital I/O module via a ribbon cable so it can be mounted in a case.

I suspect the toggle switches will make the module quite heavy, so maybe the full 80 pin connector would be a good idea for stability.

Thanks,

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/CAK9X0%2Bu7dQwEOVNopsL2Y-%3D2AgxfeLO-E5JhUVgK47Uz4wpXow%40mail.gmail.com.

[Spencer Owen]

It seems like several of us are having the same idea, and I was going to go down the toggle switch route too.  However, I think it needs headers to take the switches/leds off to a remote panel for those that are using a case of any kind.

In the meantime, for those that want to mount their switches/leds remotely, remember that pulling every third pin from a standard 0.1" header will make a convenient connector for the RC2014 Digital I/O Module

Spencer

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

[Wayne Warthen]

All of these concepts look great to me.  I certainly agree with Alan that putting the lights/switches on an actual front panel is the best thing to do.  However, I certainly have a bunch of boards and many will never wind up in a case.  I think a board like any of the modules proposed here would be very useful.

Thanks,

Wayne

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAO93Ptcx6-kEHdEw9V-3aKcbkAOfTg5iB5kEuK8E%3DsbDuUtzXQ%40mail.gmail.com.

[positron (Jose L. Collado)]

Hi Wayne, I'm testing the great new Front Panel functionality with a modded I/O card and based on the behavior of my customized ROMWBW (SC-126) seems like HBIOS config options BOOT_DEFAULT and BOOT_TIMEOUT (that I use) take precedence over the BOOT switches (i.e. my system allways boots from the configured device and slice, regardless of the position of these switches).

Do I have to change  BOOT_TIMEOUT to -1 in order to make the system boot react to these switches ?

The CONSOLE switches work as expected, responding to serial port change between Pri and Sec. Here comes another question: is there a config option to set the desired "Secondary" port ? When flipping the corresponding switch, it chanes to Dev #1; in my case an alternate console is at Dev #2.

Thanks and regards,

JL (morfeo.matrixx)

El sábado, 15 de abril de 2023 a la(s) 18:02:24 UTC-3, Wayne Warthen escribió:

[Wayne Warthen]

Some good questions Jose.  See below.

Thanks,

Wayne

On Thursday, May 4, 2023 at 4:41:19 PM UTC-7 positron (Jose L. Collado) wrote:

Hi Wayne, I'm testing the great new Front Panel functionality with a modded I/O card and based on the behavior of my customized ROMWBW (SC-126) seems like HBIOS config options BOOT_DEFAULT and BOOT_TIMEOUT (that I use) take precedence over the BOOT switches (i.e. my system allways boots from the configured device and slice, regardless of the position of these switches).

That does not sounds right.  The switches are checked first and should take priority.  To be more specific, the "Auto" switch is checked.  If it is set, then the system should ignore BOOT_DEFAULT and just boot what the switches say.  I note that you are using an SC126.  My initial 3.3.0-dev releases did not work well with the SC126.  I had the "switches" configured to use the same port as the built-in LEDs (0x0C).  However, no switches would ever be found at that port.  I subsequently updated the default configuration for SC126 to look for the switches at port 0x00 (the normal port for Digital I/O).  When your system boots, do you see a line that starts with "FP:"?  If the switches are found, you should see something like "FP: IO=0x00 SWITCHES=0x00".  If the switches were not found, you should see something like "FP: IO=0x00 NOT PRESENT".  Can you let me know what you see?  Better yet, just send me a copy of your bootup messages.

Do I have to change  BOOT_TIMEOUT to -1 in order to make the system boot react to these switches ?

No.  If the "Auto" switch is set, then BOOT_TIMEOUT is ignored.

The CONSOLE switches work as expected, responding to serial port change between Pri and Sec. Here comes another question: is there a config option to set the desired "Secondary" port ? When flipping the corresponding switch, it chanes to Dev #1; in my case an alternate console is at Dev #2.

Yeah, the current code handles "Sec" by just bumping to the next unit number.  I will take a look at what it would take to have a configuration setting for this.  It would mean using a custom ROM build, but that is not hard.

Thanks,

Wayne

[positron (Jose L. Collado)]

Hi Wayne, attached is my boot sequence capture. The problem was that I misinterpreted the AUTO/MENU switch, thinking that AUTO meant to follow hardcoded config options and MENU was the position to follow FP switches... so I flipped that switch and it works ok now!

In the special case of the SC-126 Platform (and potentially in other platforms to, I think), if you have an IO card that handles the Front Panel, you end up having two set of LEDs: the built-in DIAGNOSTIC LEDs (at port $0C) and the "proper" front panel LEDs at port $00, that pair with the switches. 

Maybe you should consider in HBIOS APIs renaming "SYSSET Subfunction 0xF4 – Set Front Panel LEDs (PANEL)"  that sets the built-in LEDS to somethin like "SYSSET Subfunction 0xF4 – Set Dianostic LEDs (BUILT-IN)" and adding a new SubFunction to set the proper FP LEDs, i.e. "SYSSET Subfunction 0xF5 – Set Front Panel LEDs (PANEL)".

I discovered this behavior when I modified "romldr.asm" to mirror switch positions (when read) to the FP LEDs at $00 using the aforementioned HBIOS API and saw the Diagnostic LEDs at $0C changing instead.

Thnas again for your lightning fast response !

Regards, JL (morfeo.matrixx)

[Wayne Warthen]

Hi Jose,

Happy to hear it is working now.  Some comments below...

Thanks,

Wayne

On Friday, May 5, 2023 at 3:51:31 PM UTC-7 positron (Jose L. Collado) wrote:

Hi Wayne, attached is my boot sequence capture. The problem was that I misinterpreted the AUTO/MENU switch, thinking that AUTO meant to follow hardcoded config options and MENU was the position to follow FP switches... so I flipped that switch and it works ok now!

Terminology and interpretation cause more problems than hardware or software ever do.  I can see how you interpreted the terminology as you did.  I am open to any suggestions that you or others have regarding the terminology I have used.  It is all on paper at this point, so easy to change!

In the special case of the SC-126 Platform (and potentially in other platforms to, I think), if you have an IO card that handles the Front Panel, you end up having two set of LEDs: the built-in DIAGNOSTIC LEDs (at port $0C) and the "proper" front panel LEDs at port $00, that pair with the switches. 

Maybe you should consider in HBIOS APIs renaming "SYSSET Subfunction 0xF4 – Set Front Panel LEDs (PANEL)"  that sets the built-in LEDS to somethin like "SYSSET Subfunction 0xF4 – Set Dianostic LEDs (BUILT-IN)" and adding a new SubFunction to set the proper FP LEDs, i.e. "SYSSET Subfunction 0xF5 – Set Front Panel LEDs (PANEL)".

Yup, the SC26 is indeed a bit of a special case.  I do love the built-in LEDs, but is a bit confusing in this situation.  However, I am reluctant to adapt the API to a single hardware platform.  While it would make sense for SC126, it would probably cause confusion for all the other platforms.  Having consistency across 25+ hardware variations is a blessing and a curse.

[Dylan Hall]

It's taken far longer than I expected, but I finally have my front panel built :)

Thanks Wayne! Everything just worked :)

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/b627278b-7add-4b1f-93a1-ef4527a16c5dn%40googlegroups.com.

[S P Dixon]

That's really nice!!  Well done.

On 12 Jun 2023, at 12:31, Dylan Hall <dy...@deedums.com> wrote:

It's taken far longer than I expected, but I finally have my front panel built :)

<IMG_0875.JPG>

<IMG_0876.JPG>

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

[Wayne Warthen]

Wonderful!  Thanks for sharing.

-Wayne

[Kevin Boone]

Hi

There was some discussion above about the ordering of the boot selection switches. For what it's worth, my view is that the switches and LEDs should be wired to the digitial I/O in natural bit order. That is, bit 7 to the left, bit 0 to the right. That way, the panel could more easily be used for other applications, if desired, once the system has booted. To be honest, I don't have a clear idea what such applications would be but, if there are any, I think it would help if there were an ordering to the switches and LEDs that did not have to be looked up in documentation.

Having said that, I should point out that I don't really have a strong view. All I really need to know is what layout is chosen, and that it's going to stay the same (or be easy to change in configuration). I'm building my front panel now, and it would good if I didn't have to rewire it later. If I had to rewire it 'virtually' in code, that's fine; but taking a soldering iron to the finished unit could be inconvenient. I imagine it would be even more inconvenient for those people who have designed custom boards and had panels printed and what-not. My panel is just a mess of point-to-point wiring, so I could resolder it, if I had to.

Best wishes
Kevin

[Wayne Warthen]

On Saturday, June 17, 2023 at 11:44:57 PM UTC-7 Kevin Boone wrote:

There was some discussion above about the ordering of the boot selection switches. For what it's worth, my view is that the switches and LEDs should be wired to the digitial I/O in natural bit order. That is, bit 7 to the left, bit 0 to the right. That way, the panel could more easily be used for other applications, if desired, once the system has booted. To be honest, I don't have a clear idea what such applications would be but, if there are any, I think it would help if there were an ordering to the switches and LEDs that did not have to be looked up in documentation.

Bit 7 is indeed on the left in the RomWBW Front Panel conceptual layout.  The layout is documented in the RomWBW User Guide starting with v3.3.  Since v3.3 is not yet releases, you must refer to the dev branch for this.

Thanks,

Wayne 

[Kevin Boone]

Hi Wayne

Thanks. It never occurred to me that the documentation would be different in the dev branch ;)

Best wishes

Kevin

[Wayne Warthen]

On Sunday, June 18, 2023 at 8:26:09 AM UTC-7 Kevin Boone wrote:

Thanks. It never occurred to me that the documentation would be different in the dev branch ;)

I do try to update the documentation as the code changes.  Unfortunately, I don't always remember.

-Wayne 

[Kevin Boone]

Actually, for something that (I presume) makes little or no money for anybody, RomWBW is strikingly well documented. I'm certainly not complaining. I work on multi-million dollar commercial software projects that have less documentation than RomWBW :)

Best wishes

Kevin

[Wayne Warthen]

On Monday, June 19, 2023 at 10:30:29 AM UTC-7 Kevin Boone wrote:

Actually, for something that (I presume) makes little or no money for anybody, RomWBW is strikingly well documented. I'm certainly not complaining. I work on multi-million dollar commercial software projects that have less documentation than RomWBW :)

I consider that a huge compliment.  Thank you.

-Wayne