Jump to content
Perifractic

Prototype #2 is aliiiive!

Recommended Posts

Posted (edited)
17 minutes ago, lamb-duh said:

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.

That's not quite correct, but Cyber's not correct, either.

Hardware actually CAN directly access RAM. It just needs to assert the DMA pin on the CPU. This suspends the CPU and lets the hardware access the bus. 

However, that's not how I/O devices usually do it. They use something called the Chip Select (CS) pin. 

Every clock cycle, every device on the bus looks at the CS pin and decides whether or not it should respond to the address and data bus. If the CS for that device is high, that device is allowed to talk to the bus. If the CS is low, that device is NOT allowed to talk to the bus.

On the Commodore 64, the device that controls the CS pin is the PLA chip. This chip examines the data bus address on every clock cycle, then sets the CS pin for every device on the system based on the current bank configuration and address on the bus. 

So when the address is in the RAM range, the PLA sets the CS pin tied to the RAM chips. When the address is in the ROM range, the CS pin for the ROM is activated. This is what allows RAM, RAM, and I/O to all live in the same address ranges and be banked in and out as needed by the operating system. 

 

Edited by TomXP411
  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

@lamb-duh @TomXP411

Ok, so I/O latches usually are physically outside the main RAM. We also call these latches "device registers". When we access them programmaticaly we actually don't care how they implemented physically, we just read or write I/O address in memory, thus communicate with device.

But speaking physically - what are these latches (registers) are? Is it internal part of actual device? Or is it just another separate RAM-like chip somewhere on board? Or it might be one or another?

Share this post


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

@lamb-duh @TomXP411

Ok, so I/O latches usually are physically outside the main RAM. We also call these latches "device registers". When we access them programmaticaly we actually don't care how they implemented physically, we just read or write I/O address in memory, thus communicate with device.

But speaking physically - what are these latches (registers) are? Is it internal part of actual device? Or is it just another separate RAM-like chip somewhere on board? Or it might be one or another?

In case of VIAs, YM-2151, VERA, the're internal to the chip.

In case of $00 and $01, they're in separate components on the board, probably in the same bunch as the address decoding logic.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
On 1/7/2021 at 2:28 PM, Cyber said:

 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.

No, 65xx family IO devices are "memory mapped", which is to say that the processor does not have any special signal to say it is talking to IO, it reads or writes to "an address", and it is up to the system design to either select RAM or select an I/O device at a particular address.

The CX16 selects IO when any one of the $9Fxx addresses are read or written to. Those are 256 addresses. In binary that is %10011111xxxxxxxx. Those eight "x"s have two different jobs. The first three select the specific device "space", the remaining five select the up to 32 addresses available for each device "space". So it could be expressed as %10011111dddaaaaa. When ddd=%000, you are selecting the VIA's. Each VIA has four address lines for a total of 16 register locations, so by using the top address line to select between the two, you can fit two VIA's in one "device space". The (updated from it's original design) VERA address space is fully populated with five address lines so the VERA occupies one whole address space.

Five of the address spaces are allocated to the cards. How that works, I won't have time to find out until after the semester ends, but there could be a dedicated select line for device spaces 4-7 (of 0-7) for for cards 1, 2, 3, and 4, and a common select line for space 3 that goes to all four card slots, which some expansion cards can take advantage of for extra I/O space. Indeed, if there was a "enable use" select bit in the "native" address space, the "common extra" 32bytes could be shared by cards if their drivers knew about each other.

Edited by BruceMcF
fix typo
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

If I want my programs now to be compatible with the older configuration (and V38 emulator) and also work with the new $00/$01 bank registers, will it be okay to simply write the same value to $9F60 and also to $00  (for rom bank) and $9F61 also to $01 (for ram bank)  or are the old bank registers repurposed and it it no longer safe to write to them like this?

(also do i have the order of $00 and $01 correct?)

  • Like 1

Share this post


Link to post
Share on other sites
Just now, desertfish said:

If I want my programs now to be compatible with the older configuration (and V38 emulator) and also work with the new $00/$01 bank registers, will it be okay to simply write the same value to $9F60 and also to $00  (for rom bank) and $9F61 also to $01 (for ram bank)  or are the old bank registers repurposed and it it no longer safe to write to them like this?

(also do i have the order of $00 and $01 correct?)

Repurposed ... those are VIA parallel ports, some of them will now be on the User Port.

Share this post


Link to post
Share on other sites
4 hours ago, TomXP411 said:

Hardware actually CAN directly access RAM. It just needs to assert the DMA pin on the CPU. This suspends the CPU and lets the hardware access the bus. 

However, that's not how I/O devices usually do it. They use something called the Chip Select (CS) pin. 

Every clock cycle, every device on the bus looks at the CS pin and decides whether or not it should respond to the address and data bus. If the CS for that device is high, that device is allowed to talk to the bus. If the CS is low, that device is NOT allowed to talk to the bus.

Ok, so will this mode be supported on the X16? I am currently thinking of developing an expansion card for communications. Moving "large" memory blocks (large in terms of X16) is very CPU intensive and requires many RAM access events.

Is getting next command from RAM/ROM in the 6502 also tied to the same bus at the same system clock? If so, moving a single byte would involve like about 10-12 clock ticks - pausing the cpu would make IO run at least 10x the speed. Am I right to this? And is this possibly supported for X16 expansion cards? 

Share this post


Link to post
Share on other sites
Posted (edited)
7 minutes ago, TheUnknownDad said:

Ok, so will this mode be supported on the X16? I am currently thinking of developing an expansion card for communications. Moving "large" memory blocks (large in terms of X16) is very CPU intensive and requires many RAM access events.

Is getting next command from RAM/ROM in the 6502 also tied to the same bus at the same system clock? If so, moving a single byte would involve like about 10-12 clock ticks - pausing the cpu would make IO run at least 10x the speed. Am I right to this? And is this possibly supported for X16 expansion cards? 

Since the expansion ports (at least to my understanding) have all 16 address lines and both the RDY and BE lines, you should be able to halt the CPU and take over the system, even going as far as replacing the 6502 with another CPU (e.g. a 65816) on your expansion card.

Edited by Guybrush

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

Technically yes, but then you have 2 devices driving the bus at the same time and they may have different timing. At best that’s a bad practice and at worst you could damage something and most of the things in between involve data corruption and unstable operation. You only ever want on thing driving the busses at any given time. The banking latches work because they never drive the bus.


Sent from my iPhone using Tapatalk
  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, Lorin Millsap said:

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.

Great minds think alike ;oD
https://github.com/commanderx16/x16-rom/issues/184

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
22 hours ago, Perifractic said:

Here is Adrian's video about the troubleshooting:

Adrian Black is a class act.  What a gracious and generous video.  I have enjoyed his channel and hope he keeps producing new content for a long time.

This is an important step.  I hope folks in the community realize how much engineering work remains between "mostly runs on the bench" and "ready for production".

Edited by picosecond
  • Like 8

Share this post


Link to post
Share on other sites
19 hours ago, BruceMcF said:

there could be a dedicated select line for device spaces 4-7 (of 0-7) for for cards 1, 2, 3, and 4, and a common select line for space 3 that goes to all four card slots, which some expansion cards can take advantage of for extra I/O space. Indeed, if there was a "enable use" select bit in the "native" address space, the "common extra" 32bits could be shared by cards if their drivers knew about each other.

Interesting assumption about common card space (I was wondering why is there 5 card spaces while board has only 4 slots).

I think somebody said something about possibility of cards communicating between each other. I think it was pretty long ago, may be on Facebook group. Or may be I'm imaginating things. 

Share this post


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

Interesting assumption about common card space (I was wondering why is there 5 card spaces while board has only 4 slots).

I think somebody said something about possibility of cards communicating between each other. I think it was pretty long ago, may be on Facebook group. Or may be I'm imaginating things. 

In one of the 2 "proto #2 working" videos, something is mentioned about five device spaces for four cards. I don't have time to listen to them again this afternoon, but IIRC, how that will work is not entirely settled.

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
On 1/7/2021 at 5:52 PM, Cyber said:

@lamb-duh @TomXP411

Ok, so I/O latches usually are physically outside the main RAM. We also call these latches "device registers". When we access them programmaticaly we actually don't care how they implemented physically, we just read or write I/O address in memory, thus communicate with device.

But speaking physically - what are these latches (registers) are? Is it internal part of actual device? Or is it just another separate RAM-like chip somewhere on board? Or it might be one or another?

Note that sometimes there ARE no registers, and the data lines drive logic directly when that address is written to. You might have a 2 to 4 decoder, connect the device select to the chip select for the decoder, a0 and a1 to the decoder input, and then $00-$03 inside the device address space generates four different select lines. Some of those select line might select logic chips to make use of the data input directly. If there are pull down resisters on those data lines, if it is read back, it would always return a $00, because the lines are essentially output only when the logic circuit is selected.

Or sometimes there is a write-only register and if your program needs to know what is in the register, it has to store the value itself, because it cannot be read.

it is possible that not all the address lines are connected ... you have a chip with two address lines, so you connect the device select line, a0 and a1, and $04-$07, $08-$0B, etc. all act like mirrors of $00-$03.

A lot of devices let you read register values back, because it's so handy ... and avoids errors when a software shadow register value is out of sync with the actual register ... but it is entirely the design of the chip or circuit that decides whether it does that.

 

Edited by BruceMcF
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
43 minutes ago, BruceMcF said:

In one of the 2 "proto #2 working" videos, something is mentioned about five device spaces for four cards. I don't have time to listen to them again this afternoon, but IIRC, how that will work is not entirely settled.

I didn't pay atteantion to this, when listened for the first time. Thank you, I found it.

Quote from "Commander X16 Hardware Changes for Proto #2" video:

Quote

Also that freed up 5 expansion ranges for the I/O bus. So my idea was really, you know, you could obviously tie a card to a specific range if you wish. Or you could use a jumper and use multiple ones on a single card if you wanted to and now you just have one more available.

 

  • Like 1

Share this post


Link to post
Share on other sites

Quote from "Commander X16 Hardware Changes for Proto #2" video:

Quote

I'm inviting someone to plug a 950 watt Corsair power supply into this board and perform some pretty incredible arc welding across the pins or frying traces on the board and all that kind of fun stuff, so currently there's pretty much no current limiting.

I see I'm a missing a point here. I know that every component has its own eaxct current drain, so the whole board will also drain needed current only, even if PSU can provide more. I know that PSU might be too low on power, when board drain more current, than PSU can provide. But how can it be vice versa, how can it be too much power?

Share this post


Link to post
Share on other sites
Quote from "Commander X16 Hardware Changes for Proto #2" video:

I'm inviting someone to plug a 950 watt Corsair power supply into this board and perform some pretty incredible arc welding across the pins or frying traces on the board and all that kind of fun stuff, so currently there's pretty much no current limiting.

I see I'm a missing a point here. I know that every component has its own eaxct current drain, so the whole board will also drain needed current only, even if PSU can provide more. I know that PSU might be too low on power, when board drain more current, than PSU can provide. But how can it be vice versa, how can it be too much power?

 

It’s too much power when you make a mistake and fry something catastrophically. We are looking at implementing perhaps self resetting fuses or something.

 

 

Sent from my iPhone using Tapatalk

Share this post


Link to post
Share on other sites
Posted (edited)

Isn't this answered by our beloved formula U=RI => I=U/R?

That is, the amount of current drawn by a circuit depends on the voltage and the overall resistance, not how many watts the PSU may supply.

Edited by Stefan

Share this post


Link to post
Share on other sites
12 minutes ago, Stefan said:

Isn't this answered by our beloved formula U=RI => I=U/R?

This is, the amount of current drawn by a circuit depends on the voltage and the overall resistance, not how many watts the PSU may supply.

Yes. That's why I'm confused as well. But if I understood @Lorin Millsap correctly, if you make a mistake, i.e. make a short circuit accidently, then the scale of damage will be proportional to PSU power.

Share this post


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

Yes. That's why I'm confused as well. But if I understood @Lorin Millsap correctly, if you make a mistake, i.e. make a short circuit accidently, then the scale of damage will be proportional to PSU power.

True.

Also answered by I=U/R => During a short R is close to 0 Ohm and I is close to infinity Amps (but in reality the amount of amps provided by the PSU).

Almost everything I know about electricity is contained within those three letters 🙂

Share this post


Link to post
Share on other sites

I just now had another thought... Does electrical breakdown is relevant here? Technicaly it should not be, because it happens beacause of too high voltage and not because of too high PSU power. I'm still learning, so I'm not sure about these things...

Share this post


Link to post
Share on other sites
5 hours ago, Lorin Millsap said:

IIt’s too much power when you make a mistake and fry something catastrophically. We are looking at implementing perhaps self resetting fuses or something.

I thought we were keeping things simple.

A fuse is not going to protect any ICs from metal objects and clumsy fingers.  At best it will avoid vaporizing some main power traces that got treated to a dead short.  If someone accidentally does that, lesson learned and break out the rework wire.

Share this post


Link to post
Share on other sites
6 minutes ago, picosecond said:

I thought we were keeping things simple.

A fuse is not going to protect any ICs from metal objects and clumsy fingers.  At best it will avoid vaporizing some main power traces that got treated to a dead short.  If someone accidentally does that, lesson learned and break out the rework wire.

Fuses are cheap though, even self resettable ones. I thought the main reason for fuses were fire. I agree, if you short something, there is probably damage. But also consider most of the components are through hole and socketed. So saving the traces here is probably worth the small extra expense.

Share this post


Link to post
Share on other sites

That is it exactly. So picture if you will soldering one of these boards yourself and you make a mistake and say for example happen to bridge a power and ground. That short may not damage any chips but it could potentially vaporize a trace.

 

In theory most power supplies are going to be able to detect dead shorts and shut off themselves but you can’t really rely on that because they might still allow an awful lot of current before they sense it as a short.

 

I for one feel that putting some kind of fuses that are some value we consider normal and safe would be better than just allowing The power supplies full output unrestricted.

 

 

Sent from my iPhone using Tapatalk

  • Like 2

Share this post


Link to post
Share on other sites
15 hours ago, BruceMcF said:

In one of the 2 "proto #2 working" videos, something is mentioned about five device spaces for four cards. I don't have time to listen to them again this afternoon, but IIRC, how that will work is not entirely settled.

I think that all of the CS lines will be present on each card slot, which makes it up to the expansion device to operate on the correct CS pin. 

This will probably mean a jumper block on the card, which connects to the correct pin on the slot. Someone could devise a PnP system that sets the correct CS line through software, but I don't see much utility in that when a 10-pin jumper block costs next to nothing.

 

 

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