Jump to content
Perifractic

Prototype #2 is aliiiive!

Recommended Posts

yes indeed.
But my point was about coherence (there aesthetics too).
It is more coherent to have all "related" things at the same place.
Here, we will have 2 system switches in the ZP, all others in $9F00.

So as the ZP is faster to access, let's have all the sys switches in the ZP. 
Anyway, I do agree it's not that important
It's just I like my system like my whisky, neat

Because the moment you do that you no longer have access to ZP for use in your programs and that is a really bad thing. Use if ZP isn’t a little faster it’s a lot faster. ZP can be thought of almost like 256 processor registers. The 6510 had an IO port built in at $00 and $01.


Sent from my iPhone using Tapatalk
  • Like 1

Share this post


Link to post
Share on other sites
  
Same thoughts here, so I also don't understand the point of ATX PSU yet...  
But I patiently hope X16 team will reveal the reasons.

Because the price deal on the cases gives us a power supply built in. It’s less expensive than sourcing an external low noise power supply and it gives us multiple voltages.


Sent from my iPhone using Tapatalk
  • Like 2
  • Thanks 2

Share this post


Link to post
Share on other sites
1 minute ago, Lorin Millsap said:


-1- Because the moment you do that you no longer have access to ZP for use in your programs and that is a really bad thing.

-2-Use if ZP isn’t a little faster it’s a lot faster. ZP can be thought of almost like 256 processor registers.

-3- The 6510 had an IO port built in at $00 and $01.
 

.1 utterly correct. I was simply being the devil advocate. 

.2 Ganz Genau. Again, right to the point

.3 That does mean it's right ;oD

Share this post


Link to post
Share on other sites

Because the price deal on the cases gives us a power supply built in. It’s less expensive than sourcing an external low noise power supply and it gives us multiple voltages.


Sent from my iPhone using Tapatalk
Thank you! That's very clear point.
But why not just put a rocker switch on "power on" and "ground" pins of PSU?
  • Like 1

Share this post


Link to post
Share on other sites

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....

Share this post


Link to post
Share on other sites
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

  • Like 2
  • Haha 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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
  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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
  • Like 3

Share this post


Link to post
Share on other sites
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.
  • Like 2

Share this post


Link to post
Share on other sites

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

  • Like 4

Share this post


Link to post
Share on other sites
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 !

Share this post


Link to post
Share on other sites
On 1/5/2021 at 4:18 PM, kktos said:

As a dev, I'm a tad displeased by the change for Bank Switching to ZP $00/$01.....
Not coherent with all the other system switches (mem location wise, I mean).
Taking 2 addresses on the tiny and already packed ZP.
Am I the only one ?

Not really, given that the ZP is NOT already packed ... at least, compared to the tiny amount of free User zero page space available to the C64, $02 to $7F is a big slice of zero page for assembly language programs even when called by Basic as SYS routines.

And it was heading toward having almost no User Port capabilities at all, while now it has more GPIO available than the C64 User Port had.

  • Like 1

Share this post


Link to post
Share on other sites
20 hours ago, kktos said:

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

Part of the benefit of the emulator seems like finding out where that was a bottleneck in juggling access to internal VERA registers, especially for things like running sound on an interrupt loop while pumping graphical data into the "VRAM", leading to a change to the Vera design to map a critical range of internal registers directly into the address space, occupying the full 32 byte range for a single memory mapped device.

It's certainly cleaner for the "mirrored bank register latch" approach to be selected in the bottom half of RAM when all of the address space CONTROLLED by the latches are in the TOP half of RAM ... and if selected independently of the select logic for the ROM and RAM banks, there is no simpler space in the bottom half of RAM to select for than $0000/$0001.

And of course, for anything ported from or made to be portable to the C64, the internal I/O port in the MOS6510 at $0000/$0001 means that things like a Sweet 16 engine already starts somewhere above $0001.

  • Like 2

Share this post


Link to post
Share on other sites

Part of my thinking as I’m the one who pitched the ZP banking feature to Kevin was that by making it a ZP feature it speeds up all banking operations. This includes many KERNAL functions since those are often in banked ROM, as well as user code that uses banked RAM.

 

Admittedly in theory using ZP for VERA makes some sense for speeding up access, the added circuit complexity isn’t desirable and you have to be aware that the more memory decoding you add the more potential it has to add unwanted timing delays which could result in stability issues.

 

On this I suppose I should clarify how the latches basically work and to do that I need to explain how the normal IO space works.

 

So as you know there is a RAM and ROM in the base 64k memory map. By default the RAM is selected with exclusions. If the address lands in the ROM memory range the RAM is excluded and the ROM gets addressed instead. The same is true for the banked RAM range. This also applies to the IO range. This allows any of the chips in those ranges to be addressed correctly without any bus contention.

 

However how the zero page latches work is a little bit different. The latches “shadow“ the ram. Basically the latches themselves are write only. When you write to $00 or $01 you write to RAM and the latches. The RAM is not excluded the way it is for other address ranges. When you read $00 or $01 you are reading from RAM.

 

Now if you wanted to move VERA to zero page you would need to add exclusion logic to the RAM so that it doesn’t conflict. But every bit you add does 2 things. Firstly your part count goes up which drives up cost, but also you add propagation delays which if you get enough will cause unstable operation or non operation.

 

 

Sent from my iPhone using Tapatalk

  • Like 7

Share this post


Link to post
Share on other sites
Posted (edited)

Moving the bank registers to zero page only makes sense if it is also possible to read them. It is useful to allow calls between banks using a trampoline (bank switcher) in non-banked memory. Such trampoline needs to push the bank number together with the return address so that it later can return via another trampoline to the caller (switching the bank back).

If reading is not possible, a shadow bank number could be written to RAM, but that would mean writing the bank twice which defeats the gain of having it in zero page.

Edited by hth313
improve grammar

Share this post


Link to post
Share on other sites
Moving the bank registers to zero page only makes sense if it is also possible to read them. It is useful to allow calls between banks using a trampoline (bank switcher) in non-banked memory. Such trampoline needs to push the bank number together with the return address so that it later can return via another trampoline to the caller (switching the bank back).

If reading is not possible, a shadow bank number could be written to RAM, but that would mean writing the bank twice which defeats the gain of having it in zero page.

I think you misunderstood me you can read them technically the value stored in RAM and the value stored in the registers should always be the same. The only exception is during initial power up the ram might contain random values but is soon as the post rouroutine writes the bank it will immediately be updated and match. There is no condition once it is set where the value you read back will ever be different than the actual value stored in the latch.

 

Sent from my iPhone using Tapatalk

  • Like 6

Share this post


Link to post
Share on other sites

Nice job by Adrian in explaining what the issue was.

Sounds like Kevin was so close, but as Adrian said, it just needed a second set of eyes to look at it a little differently.

  • Like 1

Share this post


Link to post
Share on other sites

  I'm still learning these things, so please forgive me for my dumb questions. I ask them to better understand how things work.
 

10 hours ago, Lorin Millsap said:

So as you know there is a RAM and ROM in the base 64k memory map. By default the RAM is selected with exclusions. If the address lands in the ROM memory range the RAM is excluded and the ROM gets addressed instead. The same is true for the banked RAM range. This also applies to the IO range. This allows any of the chips in those ranges to be addressed correctly without any bus contention.

I already knew this about the ROM. And it sounds clear for me about banked RAM.
But speaking about IO... I thought that IO range is actually stored in RAM, and each device has access to its own RAM range inside IO range. So am I wrong? From Lorin's quote above it seems like each device has its own latches to store its data.
 

10 hours ago, Lorin Millsap said:

Now if you wanted to move VERA to zero page you would need to add exclusion logic to the RAM so that it doesn’t conflict.

Why would it conflict? If I move VERA registers to zero page, shouldn't VERA register values be technically always the same as RAM values? What am I missing?

Share this post


Link to post
Share on other sites
55 minutes ago, Cyber said:

But speaking about IO... I thought that IO range is actually stored in RAM, and each device has access to its own RAM range inside IO range. So am I wrong?

hardware can't directly access ram because only one address can be read from ram at a time, and the 6502 does a memory read or write nearly every cycle. so, communication with hardware needs to be done with latches that are (physically) outside the main ram.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use