Just patting myself on the back...

[Bill E]

Sorry. I've been doing some timing tests and such to be sure things haven't broken. Timed the drum. DEC says 'approximately' 35 msec for a full 4096 word track transfer. Timed mine. 34.816 msecs, which also happens to be exactly the value you get if you look at the original drum timing of 8.5 usec/word. Not bad if I do say so myself. :)

OTOH, the individual per-word time isn't quite accurate, 8.5usec is not a convenient multiple of the 5usec cycle time, it's only exact every multiple of 17 words. But, this internal timing isn't visible, it's just annoying to me. Aap would not be happy. But, the overall time is exact for any word count and is the delay you will get doing an IOT i or c.

Bill

[Angelo Papenhoff/aap]

very nice! i'll have to think of the drum sometime. my current idea is just pretending to do a HSC but with a pretended break and restart of the time chain. hopefully i get to that soon, so many to-do's :)

[Bill E]

Thanks, you probably won't like some of the internals. As we talked about, it really doesn't quite fit with the 1C memory architecture, but outside the IOT, the timing is pretty realistic, better for longer transfers.

Its also using my HSC in 'cheat' mode. My HSC can do the proper cycle-stealing, but the drum IOT has it just do immediate memory transfers then simulates the HSC timing inside the IOT. Why? Well, a bad reason, actually. I didn't want to have to wait 32 whole msecs for a full-track transfer, so I can make the drum request then ignore the completion time. Ok, that's pretty lame. Maybe I'll change it and let the HSC cycle-steal.

Bill

PS - it's interesting that the real HSC just takes over the memory for as long as there is data to transfer. From my reading, nothing else gets processed, including breaks. Locking out the processor for that long seems a bit strange.