-
Notifications
You must be signed in to change notification settings - Fork 23
Ed's Diary 2016 05 12
Ed at Dave's thu 2016-05-12
(Second joint session on pidirect project)
Dave was seeing less reliable behaviour than Ed was. Dave's Beeb is more fully loaded and he's using a TTL breadboard level shifter which only pulls up to 3.3 and has scope probes connected to the tube cable.
Dave found and reverted a small change in handling IRQs while masked and that improved things, although we don't understand.
We have a number of bugs or observations:
- Sometimes Basic loading hangs
- and we determined that the parasite is seeing only 255 bytes to fetch instead of the full 256 ? did we miss a Tube access entirely? ? did we mess up the FIFO emulation and status updates?? ? did we think a Tube access cycle was a glitch when it wasn't ? or something else??
- Tube Elite draws random stuff and eventually crashes
- this is worse with slow c-based lib6502 and better with fast 65tube
- one of Dave's CPUs is more glitchy and the other is more stable
- the Tube silencer is less problematic than the breadboard converter
- ESC during clocksp benchmark reports a garbage error message
- but only with the slow c-based lib6502 core
- ESC during LIST means next LIST will respond with Syntax Error
- Language transfer always hangs using the GODIL in the CPU socket
- so the GODIL timing is too unforgiving
- even with the silencer and with fast 65tube code
- we see transfers of much less than 4k at best, and usually nothing
- whereas with a real CPU it usually works, and fails having transferred half or more
- in other words the same error (perhaps) kicks in much much earlier
- While control-break is fine, break alone does not load basic
- seems always to be true in all experiments
- Dave realises it's because we have an over enthusiastic Reset response
- fixed!
We can compare with the SPI bridged soft copro but we haven't yet We can compare a master or an unexpanded beeb
Dave added some safety code
- detect and report overrun
- detect and report if final sample (just after clock falling edge) has tube not selected (which we think could happen if we ran all the way into the following cycle)
Dave's CPUs:
- GODIL - very unhappy, could perhaps have the timing tweaked
- SY6502A (original equipment) - most sensitive to late data
- UM6502CE 4MHz - modern NMOS chip - intermediate results
- R65C02P2 - seems most forgiving and most stable
- but only when using Dave's breadboard converter
- on the silencer it fails to load Elite fully
Idea: in a read cycle (host reads the Tube) where we think we might be delivering data late, where we think perhaps 1 is more likely to be misread as 0, perhaps we could precharge the bus with FF - which is easy because we don't need to marshall the split nibbles so we can be a little earlier.
We can choose to drive the bus first and then set the outputs to FF, or vice versa.
But sadly in either case we find Elite puts up the splash screen and then locks up host side.
There are a couple of possible small improvements to the time critical code including some reordering to use the pipeline better and software pipelining from one invocation to the next
- a couple of which we've made, and it hasn't entirely fixed Elite
We could measure data arrival times on a scope. In persistent mode we can see the range of late delivery for host reads.
Back to Development Diary
Hardware
Software
- Build dependencies
- Running cmake
- Compiling kernel.img
- Deploying on a Pi
- Recommended config.txt and cmdline.txt options
- Validation
- Compilation flags
Implementation Notes