With bit-stream it'll take: 36 cycles (on average) (or ~11 opcodes) to read a nibble. loop 3 cycles (branch taken, no page cross)Ĭurrently it takes: 4+2 = 6 cycles (or 2 opcodes) to read a nibble The advantage of just dealing with the bitstream model is it's just a single format that AppleWin deals with, instead of having to support both nibble & bitstream.īPL. nib format (and further lost when converting. These would just be lost when converting back to. writing, AppleWin would now get a bitstream with extra zero-sync bits. reading, (I think) AppleWin wouldn't need to insert any extra (zero/sync) bits, as all nibbles are already in sync.Īnd when writing (or formatting) using an internal bitstream representation, but using a. nib image file to an internal bitstream representation: So the next step might be to "lower" (ie. nib images already exist in nibble track format). Currently all disk access is done at the nibble level (ie.dsk/po etc are converted to nibbles tracks and. Yes, I agree with that - we should strive not to lose any performance.Ī simple way forward would be to convert all disk access to a bitstream model. The existing disk code is, to use the made-up buzzword, performant, and it would be a shame to lose that. I wasn't really aware of these things (I've not read Sather's explanation in detail yet). Reading behaviour, so bit-stream changes are needed in the soft-switch code There's currently no convenient abstraction point in the code to switchĪs you can see with my points above, the soft-switch accesses change the The problem with keeping both byte and bit-stream disk access is that Though I suppose tools both in emulation and out could fill the gap for WOZ. That said, DO, PO and NIB images are very convenient to inspect and edit, Standard - closer to the behaviour of real hardware. Perhaps this is the best way, since I think WOZ images will become the new Time and then saved to WOZ images if necessary. One advantage would be that non-standard formatting can be written at any So when writing nibbles from DSK etc or NIB to the buffer we can just Model, which IIRC is what MAME and OE have done. The existing disk code is, to use the made-up buzzword, performant, and itĪ simple way forward would be to convert all disk access to a bitstream Some of the sequencer code is redundant - namely that to detect zeroes,Īnyway, the real question is how to shove bit-stream disk access into C08D resets the sequencer - used in the bit-slip (E7) protection and longer if 0's come along (this is howīit copy programs detect "sync bytes/nibbles") When the high bit is set then the sequencer loops while the latch holds Shift bits, and generate spurious ones if thereīut the real-time specifics get a bit tricky eg: Yes, there will be a few interesting cases to test.īTW, your program sums up the basic logic of the sequencer and transitionĭetection amplifier well.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |