Prototype #2 is aliiiive!

Announcements by the development team or forum staff.
User avatar
StephenHorn
Posts: 565
Joined: Tue Apr 28, 2020 12:00 am
Contact:

Prototype #2 is aliiiive!

Post by StephenHorn »



Just now, kktos said:




Just thinking.... as we have crossed the bridge already and placed system switches in ZP, what about VERA's ?

They are pretty often accessed so to have the ZP short & fast access may be beneficial for the whole system....



RAM/ROM banks is 2 addresses.

The VERA is 32 addresses.

Please no, and thank you. :3

Developer for Box16, the other X16 emulator. (Box16 on GitHub)
I also accept pull requests for x16emu, the official X16 emulator. (x16-emulator on GitHub)
Fnord42
Posts: 74
Joined: Fri Aug 14, 2020 8:56 am

Prototype #2 is aliiiive!

Post by Fnord42 »



31 minutes ago, Cyber said:




But why not just put a rocker switch on "power on" and "ground" pins of PSU?



I had the same thought, but: I'm pretty sure a momentary switch is part of the case by default. It might be possible to swap it out against a locking switch. (Is that the correct name? Think of the C64 shift lock key, or those "Turbo" buttons that PCs had back in the 90s.) But since this probably needs to be done by hand, I'm not sure if it doesn't turn out to be more work overall in the end.

Regarding the use of a microcontroller for the power switch logic: I would be totally fine with that, since it serves a very narrowly defined purpose. To keep the "only readily available parts" paradigm intact, the firmware should of course be available, in case you ever need to replace the chip. However, I also unterstand the desire to avoid microcontrollers at all when possible.

kktos
Posts: 50
Joined: Wed Dec 09, 2020 4:32 pm

Prototype #2 is aliiiive!

Post by kktos »



2 minutes ago, StephenHorn said:




RAM/ROM banks is 2 addresses.



The VERA is 32 addresses.



Please no, and thank you. :3



:oD

32 ? ok, seriously, I thought only about the VAddr (3), VData0 (1), VData1 (1) and VCtl (1)

Perifractic
Posts: 511
Joined: Sat Apr 25, 2020 4:53 pm

Prototype #2 is aliiiive!

Post by Perifractic »

Thank you! That's very clear point.
But why not just put a rocker switch on "power on" and "ground" pins of PSU?
Because it isn't as simple as typing "just put a rocker switch".

Every change we make from stock on the perfect case that we finally found, adds thousands of dollars.

It also changes the design aesthetic. Can you find a rocker switch that sits at a diagonal slanted angle with a skewed top and bottom?

This is a huge conversation that is not one we really need to have at this late stage. The best thing you can do is trust that every single tiny decision that we have made is in the best interests of delivering a product faster and better value than if we went with the alternate decision [emoji106][emoji973]️
troj
Posts: 74
Joined: Sun May 03, 2020 11:38 am

Prototype #2 is aliiiive!

Post by troj »



10 minutes ago, Perifractic said:




Every change we make from stock on the perfect case that we finally found, adds thousands of dollars.



Not to mention time.  Those decisions take time, designing them takes time, implementing them takes time, testing them takes time.

I just hope the resolution of the soft power issue doesn't consume too much of Kevin's time! I know the entire team has already invested a tremendous amount of that very valuable resource.

User avatar
Cyber
Posts: 482
Joined: Mon Apr 27, 2020 7:36 am

Prototype #2 is aliiiive!

Post by Cyber »



22 minutes ago, Perifractic said:




The best thing you can do is trust that every single tiny decision that we have made is in the best interests of delivering a product faster and better value than if we went with the alternate decision emoji106.pngemoji973.png



I think I just overreacted when I heard about obstacle concerning complicated power on function.

I'm sorry. I trust the team.

Lorin Millsap
Posts: 193
Joined: Wed Apr 29, 2020 6:46 pm

Prototype #2 is aliiiive!

Post by Lorin Millsap »

Just thinking.... as we have crossed the bridge already and placed system switches in ZP, what about VERA's ?
They are pretty often accessed so to have the ZP short & fast access may be beneficial for the whole system....

Apart from Stephen’s comment it would also be a logic nightmare. You can’t just randomly place whatever you want wherever in the memory map. There are reasons why things are put where they are.


Sent from my iPhone using Tapatalk
Perifractic
Posts: 511
Joined: Sat Apr 25, 2020 4:53 pm

Prototype #2 is aliiiive!

Post by Perifractic »

I think I just overreacted when I heard about obstacle concerning complicated power on function.
I'm sorry. I trust the team.
No problem! I'm glad my clarification of what goes on behind the scenes was useful.
picosecond
Posts: 70
Joined: Thu Jul 02, 2020 2:47 am

Prototype #2 is aliiiive!

Post by picosecond »


Here are some thoughts for @Kevin Williamsabout his latest video, "Commander X16 Hardware Changes for Proto #2".

I see several youtube commenters suggesting an MCU for debounce and soft power-on.  I attached some ideas for jellybean logic implementations for these.

The debounce is a standard RC delay followed by a Schmitt trigger.  There is plenty of literature available for this circuit, some of which I referenced below.  The reset debounce includes a power-on reset for the 65C02.

The first soft power-on is a light modification of the one featured in Kevin's video.  It replaces the 555-based debounce with a Schmitt trigger, adds initialization for the toggle flop and removes the unnecessary Q2 (ATX PS_ON# is TTL compatible)

The second soft-power-on is mostly stolen from http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/push-button-switch-turn-on/latching-toggle-power-switch.  The latch is built using a weak feedback inverter, similar to how SRAM bit-cells are constructed.  Pressing the switch overrides the feedback to change the state of the latch.  The circuit should oscillate if the switch is pressed indefinitely, so the RC time constant is a trade-off between responsiveness and unwanted state changes.

Disclaimer:

None of these circuits have been tested or simulated.  RC time constants likely need some adjusting and there may be more serious errors.  Fortunately it is simple to breadboard these circuits to do testing with actual switches and power supplies.  At the very least I hope they provide some inspiration and provoke discussion.  Cheers.

References:

https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-1 (total of 9 parts)

http://www.ganssle.com/debouncing-pt2.htm

http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/electronic-circuits/push-button-switch-turn-on/latching-toggle-power-switch


cx16 debounce.pdf
kktos
Posts: 50
Joined: Wed Dec 09, 2020 4:32 pm

Prototype #2 is aliiiive!

Post by kktos »



12 hours ago, Lorin Millsap said:




-1- Apart from Stephen’s comment it would also be a logic nightmare.



-2- You can’t just randomly place whatever you want wherever in the memory map.



-3- There are reasons why things are put where they are.

 



Then again, straight to the point: ) Excellent, now we're talking.

-1- hum... are you certain of that ? Here I guess there is a A15-A1=0 to select the bank switches (A0=0 RAM A0=1 ROM) If you add the VAD, VD0, VD1 and VCTL, you will need 8 bytes.....  ?

-2- obviously correct

-3- I hope so ;oD

Anyway, let's call it a day on the subject. And I do thank you for the exchange. Even if it would have been better around a pint ?

Cheers !

Post Reply