mos_8502 :verified: on Nostr: We think of chips as these black boxes that take inputs and give outputs. That ...
We think of chips as these black boxes that take inputs and give outputs. That mindset works, most of the time.
But at a certain point, you have to contend with the fact that you're dealing with real objects that obey the laws of physics, which means nothing is instant, all processes take time to complete, and sometimes things can interfere with each other.
In the case of Sentinel 65X, if care is not taken in managing the boot-up sequence, the unconfigured FPGA can cause some spurious behaviour while it configures itself, which can, sometimes, make the CPU crash. The solution came to me last night:
The W65C265S does not actually require external RAM or ROM to function as long as it has code in its internal RAM or ROM to run.
So what I do at boot time is, I hold the VERA in reset manually, delay for time X to make sure the reset takes effect, then copy a routine from external ROM to internal RAM, and jump to that routine in internal RAM.
That routine then *shuts off* the external address and data buses, thus protecting the CPU from any noise on the bus, before allowing the VERA to activate, and waiting for time Y to make sure it's done before re-activating the external bus and returning control to the external ROM.
Clever, no?
#Sentinel65X
Published at
2024-06-11 22:53:44Event JSON
{
"id": "aa7ab6aabbbc3abcfe6c0c75861393d3557895fe1df55589537823ecb5bb587d",
"pubkey": "04f8915424c713657ad6ce59443d28dbdcf5832687c9af560ae388f59276a137",
"created_at": 1718146424,
"kind": 1,
"tags": [
[
"proxy",
"https://studio8502.ca/@mos_8502/112600444064226709",
"web"
],
[
"t",
"sentinel65x"
],
[
"proxy",
"https://studio8502.ca/users/mos_8502/statuses/112600444064226709",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://studio8502.ca/users/mos_8502/statuses/112600444064226709",
"pink.momostr"
]
],
"content": "We think of chips as these black boxes that take inputs and give outputs. That mindset works, most of the time.\n\nBut at a certain point, you have to contend with the fact that you're dealing with real objects that obey the laws of physics, which means nothing is instant, all processes take time to complete, and sometimes things can interfere with each other.\n\nIn the case of Sentinel 65X, if care is not taken in managing the boot-up sequence, the unconfigured FPGA can cause some spurious behaviour while it configures itself, which can, sometimes, make the CPU crash. The solution came to me last night:\n\nThe W65C265S does not actually require external RAM or ROM to function as long as it has code in its internal RAM or ROM to run.\n\nSo what I do at boot time is, I hold the VERA in reset manually, delay for time X to make sure the reset takes effect, then copy a routine from external ROM to internal RAM, and jump to that routine in internal RAM.\n\nThat routine then *shuts off* the external address and data buses, thus protecting the CPU from any noise on the bus, before allowing the VERA to activate, and waiting for time Y to make sure it's done before re-activating the external bus and returning control to the external ROM.\n\nClever, no?\n\n#Sentinel65X",
"sig": "8a4d82811869e284b3897a70b4223466150a23fb10b7291fefdc52d1714aaffa65475e4cd04ad0c1cbefe43af138e67aac669f2fc4f8ed984d4a0371c4760cf2"
}