CSA Study App
A self-contained exam prep tool for WRES1201 (Computer Systems Architecture). Topic guide, formula reference, MCQ drills, and interactive visualizers for cache mapping, Hamming codes, and arithmetic shifts, with every number re-randomized on each reload so it never gets stale.
CSA Study App was built during finals week for WRES1201, Computer Systems Architecture, after I realized the questions I actually needed practice on (instruction mix, CPI, cache addressing, Hamming codes, disk timing) weren't well covered by any existing revision material.
Same constraint as RafiFinance: one HTML file, no dependencies beyond a CDN icon set. Every numeric question — instruction counts, clock rates, cache sizes, RPMs — is generated with randomised values each page load, so practising twice never means memorising the same answer.
Covers T1 through T10 of the syllabus, with topics outside the final exam scope (T1, T7, T9) clearly tagged so revision time goes where it actually counts.
The syllabus spans ten topic blocks. Topics tagged not-in-final are kept in the app for completeness but hidden by default with a "Focus Mode" toggle:
Most revision PDFs reuse the same five worked examples everyone has already memorised. Generating the values at runtime means the formula gets tested, not the specific numbers.
The MCQ section goes a step further: answer order shuffles independently of the question values, so guessing by position never works either.
The "By the Numbers" tiles hide a lot of formula work. This section unpacks the heavier derivations the app evaluates live, the ones students most often get wrong because they collapse several conversions into one step. Every quantity below is recomputed on each page load against freshly randomized inputs.
1. CPU performance, from instruction mix to wall-clock time. Given an instruction mix where class i occurs with frequency f_i and costs c_i cycles, the effective cycles-per-instruction is the frequency-weighted mean, and execution time folds in the clock period:
| I | total instruction count (dynamic, not static) |
| f_i, c_i | relative frequency and cycle cost of instruction class i, with \sum f_i = 1 |
| f_clk | clock frequency in Hz; t_cycle = 1/f_clk |
From here MIPS is a derived rate, \text{MIPS} = \dfrac{f_{\text{clk}}}{\text{CPI}_{\text{eff}} \times 10^{6}}, which is exactly where unit errors creep in, the 10^{6} is per million instructions, not the SI mega-prefix on the clock.
2. Amdahl's Law, the ceiling on speedup. When only a fraction p of a workload is accelerated by a factor s, the overall speedup is bounded, and the bound is brutal:
The app uses this to make a point students miss: if p = 0.9, no amount of hardware ever beats a 10\times speedup, because the serial 10\% dominates in the limit.
3. Pipelining, throughput vs. latency with latch overhead. A k-stage pipeline does not divide time by k. The clock is pinned to the slowest stage plus register-latch delay, and the pipe must fill before the first result emerges. For N instructions:
4. Cache address arithmetic, derived bitfields, not guessed. For a 2^m-byte address space, block size B = 2^b bytes, and a set-associative cache holding S = 2^s sets, the address splits into three exact bitfields:
where C is total cache capacity and A is associativity. Average memory access time then composes the hierarchy recursively:
5. Hamming SEC code, the parity inequality. To correct any single-bit error over d data bits, the number of parity bits r must satisfy the redundancy inequality, because the r check bits must address every one of the d+r code positions plus the no-error syndrome:
Each parity bit p_k (sitting at position 2^{k}) covers exactly the positions whose binary index has bit k set, and is fixed by even parity:
On read, the syndrome \mathbf{s} = H\mathbf{r}^{\mathsf{T}} is the XOR of all parity checks; if non-zero, its value read as a binary number is the 1-indexed position of the flipped bit, which is why the app can point straight at the error.
6. Disk access time, three independent latencies plus capacity. A single sector read is the sum of seek, half-a-rotation average rotational latency, and transfer time; rotational figures come from RPM, so a unit conversion is unavoidable:
RAID then applies a usable-capacity multiplier on top: N\!-\!1 drives of N for RAID 5, N\!-\!2 for RAID 6, and N/2 for mirrored RAID 1.