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"
}